Workload description

Edit online

The use of the applications DayTrader and SwingBench is described in detail, as well as the methodology for suspend and resume testing.

DayTrader

DayTrader is a benchmark application that simulates an online stock trading system.

DayTrader was originally developed by IBM® with the name "Trade Performance Benchmark Sample". In 2005, DayTrader was donated by IBM to the Apache Geronimo community . A typical user of DayTrader performs these tasks:
  • Login the DayTrader user interface
  • View the user's stock portfolio
  • Find current stock prices
  • Buy or sell shares of stock
  • Logout from the DayTrader user interface

With the aid of a Web-based load driver such as Rational® Performance Tester or Apache JMeter, the real-world workload provided by DayTrader can be used to measure and compare the performance of Java™ Platform, Enterprise Edition (Java EE) application servers offered by a variety of vendors. In addition to the full workload, DayTrader also contains a set of primitives used for functional and performance testing of various Java EE components and common design patterns

DayTrader requires a read/write data base, and was used to provide a transactional workload on WebSphere® and DB2®.

The test scenarios used DayTrader to generate a load on the WebSphere guests.

For more information about DayTrader, see:

https://geronimo.apache.org/GMOxDOC20/daytrader.html

SwingBench

SwingBench is a Java-based application that generates a workload used to run stress tests on a relational database. SwingBench comes with several predefined benchmarks, but also has the capability for the user to define their own customized benchmarks.

SwingBench has these components:
  • The load generator
  • The coordinator
  • The cluster overview

The test scenarios described in this paper used SwingBench to generate a workload on the relational database, and record statistics for later analysis. In the test scenarios, SwingBench was used for read-only transactions.

For more information about SwingBench, see:

https://dominicgiles.com/swingbench.html

Linux® Suspend and resume test methodology

The test is run as follows:
  1. A set of three guests running WAS and DB2, and three RDB guests run at constant load without z/VM® paging to warm up the environment before the first guests are suspended.
    • One of each kind is never suspended or stopped to create a base load.
    • Two of each kind are selected as system of interest to be suspended.
    • Two guests from each kind are kept inactive as standby systems.
  2. Suspend the systems of interest and start the standby servers and workload to cause memory pressure. The increasing load on the standby guests increases their need for memory. The suspended guests should become dormant and their pages should be moved to the paging space to release physical memory for the increasing need from the standby guests. The total amount of LPAR memory was adjusted to accomplish this.
  3. Reactivate the systems of interest and start the workload to get the pages moved back into main memory.

Figure 1 illustrates the processing for Test case 2 for WAS DB2 guests only. For more information about this test, see Test case 2: Pausing z/VM guests with memory pressure.

Figure 1. Test case 2: System and workload processing
Diagram that illustrates the processing for Test case 1, for WAS DB2 guests only. There are three stages from top to bottom: (1) Warmup, (2) Suspend, and (3) Reactivate. Each stage has a set of boxes representing one WAS/DB2 system for each box. Each stage has either one row of boxes or two, and each row of boxes has five systems. Systems are listed for each row from left to right. Stage (1) consists of one row of five boxes representing five systems. Three systems are active and two are in standby mode. The comment is: During system warm up, all pages are in use. Stage (2) consists of two rows of five boxes representing five systems . In the first row, one system is active, two are in suspended state, and two in standby state. In the second row, the active and suspended systems are the same, but the standby systems are now active. The comment is: Suspend the systems of interest and start the standby servers and workload to get the pages moved out of main memory. Between Stages (2) and (3) there is a notation: This is the critical phase. Stage (3) consists of two rows of five boxes representing five systems also. The first row has one active system, two resumed systems, and two suspended systems. The second row has three active systems, and two suspended systems. The comment is: Reactivate the systems of interest and start the workload to get the pages moved into main memory. Some of the boxes have a line drawn around them to indicate that they belong to set 1 or set 2 of the systems of interest. Set 1 consists of the second and third box in every row of every stage. Set 2 consists of the fourth and fifth (last) box of every row of every stage.