Workload description

Edit online

The Trade performance benchmark is a workload developed by IBM® for characterizing performance of the WebSphere® Application Server.

The workload consists of an end-to-end Web application and a full set of primitives. The applications are a collection of Java™ classes, Java Servlets, Java Server Pages, Web Services, and Enterprise JavaBeans built to open J2EE 1.4 APIs. Together, these provide versatile and portable test cases designed to measure aspects of scalability and performance. Figure 1 shows an overview of the Trade J2EE components.

This figure shows the Trade J2EE components for the workload of an end-to-end Web application and a full set of primitives. — Figure 1. Trade J2EE components

The new Trade benchmark (Trade 6) has been redesigned and developed to cover WebSphere's significantly expanding programming model. This provides a more realistic workload driving WebSphere's implementation of J2EE 1.4 and Web services including key WebSphere performance components and features.

Trade's new design spans J2EE 1.4 including

The new EJB 2.1 component architecture
Message Driven beans (MDBs)
Transactions (1-phase, 2-phase commit)
Web Services (SOAP, WSDL)

Trade also highlights key WebSphere performance components such as DynaCache, WebSphere Edge Server, and Web Services.

Trade is modeled after an online stock brokerage. The workload provides 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.

Trade provides the following server implementations of the emulated Trade brokerage services:

EJB: Database access uses EJB 2.1 technology to drive transactional trading operations.
Direct: Database and messaging access through direct JDBC and JMS code.

Type four JDBC connectors were used with EJB containers. See Figure 1 for details.

EJB 2.1

Trade 6 continues to use the following features of EJB 2.0 and leverages EJB 2.1 features such as enhanced Enterprise JavaBeans Query Language (EJBQL), enterprise Web services and messaging destinations.

Container-Managed Relationships: One-to-one, one-to-many, and many-to-many object to relational data managed by the EJB container and defined by an abstract persistence schema. This feature provides an extended, real-world data model with foreign key relationships, cascaded updates and deletes, and so on.
EJBQL: Standardized, portable query language for EJB finder and select methods with container-managed persistence.
Local and Remote Interfaces: Optimized local interfaces providing pass-by reference objects and reduced security overhead.

The WebSphere Application Server provides significant features to optimize the performance of EJB 2.1 workloads. Trade uses access intent optimization to ensure data integrity, while supporting the highest performing and scalable implementation. Using access intent optimizations, entity bean runtime data access characteristics can be configured to improve database access efficiency, which includes access type, concurrency control, read ahead, collection scope, and so forth.

The J2EE programming model provides managed, object-based EJB components. The EJB container provides declarative services for these components such as persistence, transactions, and security. The J2EE programming model also supports low-level APIs such as JDBC and JMS. These APIs provide direct access to resource managers such as database and message servers. Trade provides a Direct implementation of the server-side trading services using direct JDBC. This implementation provides a comparison point to container-managed services that details the performance overhead and opportunity associated with the EJB container implementation in WebSphere Application Server.

Note:

All the measurements done in this study used EJB.
Most enterprises now use some form of ORM tool to manage data kept in the database.

Trade provides two order processing modes: asynchronous and synchronous. The order processing mode determines the mode for completing stock purchase and sell operations. Asynchronous mode uses MDB and JMS to queue the order to a TradeBroker agent to complete the order. Asynchronous_2-Phase performs a two-phase commit over the EJB database and messaging transactions. Synchronous mode, on the other hand, completes the order immediately.

Note: All the measurements done in this study used synchronous order processing mode.

Trade provides the following access modes to the server-side brokerage services.

Standard: Servlets access the Trade enterprise beans through the standard RMI protocol.
WebServices: Servlets access Trade services through the Web services implementation in WebSphere Application Server. Each trading service is available as a standard Web service through the SOAP Remote Procedure Call (RPC) protocol. Because Trade is wrapped to provide SOAP services, each Trade operation (login, quote, buy, and so on) is available as a SOAP service.

Note:

All the measurements done in this study used the Standard access mode.
For all measurements in this study, the Trade database was populated with 2000 users (uid:0 through uid:2000) and 1000 quotes (s:0 through s:999).

Trade can run with any of the following WebSphere Application Server caching modes.

No cache: No caching is used.
Command caching: This caching feature was added to WebSphere Application Server V5.0 for storing command beans in the dynamic cache service. Support for this feature was added in Trade 3 and carried over to Trade 6.
Note: Servlet caching can also be enabled with command caching.
Distributed Map: This feature is new in WebSphere Application Server V6.0, providing a general API for storing objects in the dynamic cache service.

Note: For these tests, all of the above caching modes were examined.

In the test environment, Trade requests followed a particular path. When a Trade client issued a request, the request was routed through the first firewall, (Firewall 2 in Figure 1), to the caching proxy server, which was allowed to forward the request through the back firewall, (Firewall 1 in Figure 1), to the WebSphere Load Balancer. The WebSphere Load Balancer then forwarded the request to the Web server, which in turn, forwarded it to WebSphere Application Server. Communication between the WebSphere Load Balancer, the Web server, the WebSphere Application Servers, and the database occurred over the internal z/VM® guest LAN (Guest LAN 2 in Figure 1. Responses back to the client followed the same path, in reverse.

Detailed information about the Trade workload can be found in the IBM Redbooks® publication “Using WebSphere Extended Deployment V6.0 To Build an On Demand Production Environment” at http://www.redbooks.ibm.com/abstracts/sg247153.html

Information on how Trade works with the WebSphere Application Server can be found at http://www.ibm.com/software/webservers/appserv/was/performance.html

WebSphere Studio Workload Simulator

The Trade workload was driven by the WebSphere Studio Workload Simulator. Clients are simulated by worker threads. Increasing the number of clients increases the transaction rate or load on the Trade application running on the WebSphere Application Server. Both Command caching and Distributed Map caching were used.