Workload description

Edit online

A benchmark emulating a customer-like workload was used for the 64-bit and 31-bit WebSphere® study with J2EE workloads.

The workload was chosen to stress the middleware and J2EE components using an end-to-end Web application. The applications are a collection of
  • Java™ classes
  • Java Servlets
  • Java Server Pages
  • Web Services
  • Enterprise Java Beans (EJBs) built to open J2EE APIs
All major components of J2EE technologies are exercised, including:
  • The Web container (servlets and JSPs)
  • The EJB container
  • EJB 2.0 Container Managed Persistence
  • Java Messaging Service (JMS)
  • Message Driven Beans (MDBs)
  • Transaction management
  • Database connectivity

The workload exercises all parts of the infrastructure, such as hardware, JVM software, database software, Java DataBase Connectivity (JDBC) drivers and the system network. The workload implements a Web layer and makes extensive use of JMS and MDB technology.

The workload is a retail and manufacturing application implementing a set of user services such as login and logout, stores, buying, selling, account details, and so on, using standards-based HTTP and Web services protocols. In addition to the retail domain, a manufacturing work order domain is also simulated to drive other high-volume transactions. The retail domain uses Web layer connections to access the applications, with the manufacturing domain connecting to the application with the EJBs with the RMI protocol using RMI/IIOP.

These server connection modes are used:
EJB
Database access uses EJB 2.1 methods to drive retail and manufacturing operations.
Direct
Database and messaging access using direct JDBC and JMS code.
Type 4 JDBC connectors are used with EJB containers.

The workload is driven by the workload generator machines at a certain submission rate. Data must be present in the database before running the customer's workload simulation. The number of retailers, number of customers, and manufacturing data varies with the intended submission rate.

Scripts to load the database use an argument representing the amount of data to load. For submission rates greater than 100, they are a multiple of 100. For example, at submission rate 110 the database scripts are given an argument of 200. The database size is therefore roughly correlated with the submission rate.