Test workloads

Edit online

To ensure a customer-like scenario, a workload mix of very different workloads was chosen in which each represented a typical workload pattern. All workloads were driven in parallel.

Figure 1 describes how the software stack for these workloads was implemented on the guests.

Database BI workload within a large virtual system
Swingbench was used for the database BI workload. This is a heavy disk, memory and CPU intensive workload. This was the largest guest in the sample. For further details about Swingbench workload, see:
```
https://www.dominicgiles.com/swingbench.html
```
Transactional WAS workload
For the transactional WAS workload, an adaptation of the DayTrader workload to the WebSphere Application Server (WAS) was used. This workload was run in two load levels. For further details about the DayTrader workload see:
```
https://geronimo.apache.org/GMOxDOC22/daytrader-a-more-complex-application.html
```
Java workload
For the Java workload, a Java program was used that executed a number of parallel threads, with each thread performing the same kind of transactions. This workload was run in two load levels. This was an IBM internal benchmark.
File system I/O workload
For the file system I/O workload, the fio tool was used. fio is an I/O tool intended to be used both for benchmarking, and for stress/hardware verification. It was run with direct I/O and with page cache usage. Each of these two variants were run additionally at two load levels. For further details about, fio see:
```
https://github.com/axboe/fio
```
Network workload
For the network workload, the uperf network performance tool was used. This is a client/sever application, both components run on separate guests. Client and server part were spread into multiple processes, with each pair of processes exchanging messages through separate TCP/IP network connections. This workload was run in two load levels. For further details about uperf, see:
```
https://www.uperf.org/
```