Workload description
We used the Trade performance benchmark for our z/VM virtualization performance tests. Trade 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 Java Beans built to open J2EE 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.
The new Trade benchmark has been re-designed 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) and 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.
- EJB - Database access uses EJB 2.1 technology to drive transactional trading operations.
- Direct - This mode uses database and messaging access through direct JDBC and JMS code
Type 4 JDBC connectors are used with EJB containers. See Figure 1 for details.
EJB 2.1
- 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.
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 run-time 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.
All the measurements done in this study used EJB.
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. Asychronous_2-Phase performs a two-phase commit over the EJB database and messaging transactions. Synchronous mode, on the other hand, completes the order immediately.
All the measurements done in this study used synchronous order processing mode.
- 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.
All the measurements done in this study used the Standard access mode.
For all measurements in this study, the Trade database was populated with 500 users (uid:0 - uid:499) and 1000 quotes (s:0 – s:999).
- 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.
- DistributedMap - This feature is new in WebSphere Application Server V6.0, providing a general API for storing objects in the dynamic cache service.
All the measurements done in this study used no caching.
Detailed information on the Trade workload can be found at http://pulsar.raleigh.ibm.com. Information on how Trade works with WebSphere Application Server can be found at http://www-306.ibm.com/software/webservers/appserv/was/performance.html.
Encryption
The communication between the workload generator and the Web server occurs either in clear text using the HTTP protocol or encrypted using the HTTPS protocol with SSL.
WebSphere Studio Workload Simulator
The Trade workload was driven by the WebSphere Studio Workload Simulator and the WebSphere Studio Workload Simulator script provided with the Trade distribution. Parameters for this script can be changed via a configuration file. You can set up several different configuration files and then tell the script which file to use. The configuration changes we made are detailed in WebSphere Studio Workload Simulator Configuration file changes.
We used different copies of the modified WebSphere Studio Workload Simulator script to perform runs that were intended to stress anywhere from one to five application servers.
All the measurements done in this study used a one-to-one relationship between the WebSphere Studio Workload Simulator script and the application server.