Frequently Asked Questions |
The IBM® Trade Performance Benchmark Sample for WebSphere® Application Server (otherwise known as Trade 6) provides a suite of IBM-developed workloads for characterizing performance of WebSphere Application Server. The workloads consist of an end-to-end Web application and a full set of Web primitives. The applications are a collection of JavaTM classes, Java servlets, Java ServerPagesTM (JSPTM) files and Enterprise JavaBeansTM (EJBTM) built to open Java 2 Platform, Enterprise Edition (J2EETM) APIs. Together, the Trade application and Web primitives provide versatile and portable test cases that are designed to measure aspects of scalability and performance.
Application Design
What is Trade?
Trade is an end-to-end Web application that is modeled after an on-line stock brokerage. Trade leverages J2EE components such as servlets, JSP files, enterprise beans, message-driven beans (MDBs) and Java database connectivity (JDBCTM) to provide a set of user services such as login/logout, stock quotes, buy, sell, account details, and so on through standards-based HTTP and Web services protocols.
What are Web Primitives?
The Web primitives leverage the Trade infrastructure to test specific features of the WebSphere Application Server J2EE 1.4 programming model. A description of each of the Web primitives is provided on the main web primitive page.
Why is there a Version 6?
The Trade version skipped from Trade 3 directly to Trade 6 in order to match the WebSphere Application Server version. Trade 6 builds on Trade 3 by extending the programming model from J2EE 1.3 to J2EE 1.4.
What is new in Version 6?
As previously mentioned, the largest change in Trade 6 has been the conversion from J2EE 1.3 to J2EE 1.4. This conversion involves updating the deployment descriptors and has little impact on the actual application code. Other changes in Version 6 include:
DistributedMap
data caching as well as the ability to configure data caching within Trade from the Configuration pageWhat changes are made to the cluster configuration?
In previous versions of WebSphere Application Server, embedded messaging, based on WebSphere MQSeriesTM, running on a separate node defined outside of the Trade cluster handled the JMS portion of the Trade workload. In this release, the embedded messaging provider is replaced by an in-process, Java-based distributed messaging engine that provides workload management, failover, and partitioning capabilities. These capabilities provide a wide range of configuration options for messaging. To demonstrate the most common configuration and to high-light several of these capabilities, the following cluster configuration is used for Trade 6.
For additional details concerning the configuration of JMS in an ND and cluster environment in WebSphere Application Server V6.0, please consult the Information Center.
Installation
What software is required to run Trade 6?
What are the most common configuration scenarios?
Run-time Configuration
What does the ResetTrade link do?
The ResetTrade link on the configuration page must be clicked between Trade runs. This link sets the database to a consistent size by removing all the newly registered users created during a Trade run. The reset also sets all outstanding orders to a consistent state. Resetting the database to a consistent size ensures repeatable throughput on subsequent Trade runs.
How are the Trade configuration parameters modified?
The Trade configuration page provides a dynamic mechanism to set the run-time configuration for a Trade run. These settings control the application run-time characteristics such as the run-time mode, the order processing mode, and other run-time variations supported in Trade. All settings are reset to defaults when the Trade application server is restarted.
Note: To set configuration parameters when running in a cluster, access each application server in the cluster on its internal HTTP port (9080) and configure the run-time parameters. Another solution is to use the method for making settings permanent as described in the following section.
Can you make configuration changes permanent?
Yes. Normally, Trade configuration parameters return to defaults whenever the Trade application server is restarted. Settings can be made permanent by setting the configuration values in the servlet init parameters of the TradeApp servlet and the TradeScenario servlet. Modify the servlet init parameters in the web.xml file of the Trade Web application to change these parameters.
What are the run-time modes?
Trade provides two server implementations of the emulated Trade brokerage services.
What are the order processing modes?
Trade provides an asynchronous order processing mode through messaging with MDBs. The order processing mode determines the mode for completing stock purchase and sell operations. Synchronous mode completes the order immediately. Asynchronous mode uses MDB and JMS to queue the order to a TradeBroker agent to complete the order. Asychronous_2-Phase performs a two-phase commit over the EJB database and messaging transactions.
What are the access modes?
Trade provides multiple access modes to the server-side brokerage services.
What are the caching Types?
This setting determines which set of dynamic caching technology is used by Trade for data caching. By default, data caching is disabled in Trade.
What is the Primitive Iteration setting?
By default, the Trade primitives run one operation per Web request. Setting this value alters the number of operations performed per client request. This is useful for reducing the amount of work that is performed by the Web Container and for stressing other components within the application server.
Benchmarking
What is the TradeScenario servlet?
The TradeScenario servlet provides a simple mechanism to drive the Trade application.
The Trade database is initially populated with a set of fictitious users
with names ranging from uid:0
to uid:499
and a set of stocks ranging from s:0
to s:999
. The TradeScenario servlet emulates
a population of Web users by generating a specific Trade operation for
a randomly chosen user on each access to the URL. To run the TradeScenario servlet
use the single TradeScenario URL (http://hostname/trade/scenario) with a load generation tool.
Although TradeScenario servlet provides a simple mechanism for driving the Trade application, there is a drawback to using this method versus using a series of load generation scripts that drive the operations directly. This servlet consumes processing resources on the server to manage incoming clients and dispatch these simple client requests to complex Trade actions. This action artificially decreases server throughput because the server is emulating tasks that are normally performed by a standard client or a more complex load generation tool.
Why does performance decrease over time?
If Trade runs for an extended time, performance eventually starts to decline. This degradation in throughput is a direct result of new users, orders, and holdings accumulating within the Trade database. As the database grows, queries take longer to complete, resulting in higher response times. When the workload is stopped, the Reset Trade link can be followed to reset the Trade run-time by logging off all users, removing new registrations, and other general cleanup.
What is the typical procedure for collecting performance measurements with Trade?
When Trade is successfully installed on the application server and the supporting database is populated, you can us the Trade application to collect performance measurements. The following list provides the typical process for gathering performance measurements with Trade.