RSA key size 2048-bit
Results for tests performed for scenario 2 using RSA key size 2048-bit are discussed in this topic.
DayTrader transaction throughput and IBM WebSphere® Application Server LPAR CPU load
Figure 1 shows the normalized DayTrader SSL transaction throughput, when scaling the cryptographic setup and using a 2048-bit RSA key.
The green bar and the blue bars (dark) in the diagram show the DayTrader SSL transaction throughput for each considered cryptographic setup. The throughput number from the "IBM WebSphere Application Server (WAS) Software" setup (green bar) defines the 100% baseline for the other cryptographic setups.
Observation
The transaction throughput can be doubled when using the IBM® System z® cryptographic features.
Conclusion
Approximately 50% of the throughput increase can be attributed to CP Assist for Cryptographic Function (CPACF) and another 50% to Crypto Express3 (CEX3) for this type of workload. A second CEX3 processor does not result in higher throughput numbers, because a single CEX3 processor is sufficient to handle the workload. For the 2-CEX3 setups the zcrypt device driver does a load-balancing among the available CEX3 processors.
The WAS LPAR where the IBM HTTP server (IHS) runs is equipped with 4 Integrated Facilities for Linux® (IFLs).
Observation
All 4 IFLs are almost fully used on the WAS LPAR across all cryptographic setups in this scenario (see yellow/light bars). Additional application benchmark runs with a reduced number of clients and hence less CPU load showed similar ratios for the scaling factor of the cryptographic setups.
Conclusion
For the setups with IBM System z cryptographic features, CPU time is freed due to offloading cryptographic operations to the cryptographic features. The freed CPU time can be used to handle a greater amount of transaction requests compared to 'WAS Software' setup. This leads to a higher SSL transaction throughput number in total for the setups exploiting the IBM System z cryptographic features.
DayTrader transaction CPU costs
Another important aspect with respect to the throughput numbers reached is the amount of CPU required to drive the workload, which is considered as a cost factor. This metric is calculated as the amount of CPU needed to drive a certain amount of transactions. Figure 2 shows the CPU costs, when a 2048-bit RSA key is used.
The chart shows the CPU costs for the SSL transactions when a 2048-bit RSA key is used. The numbers are normalized against the 'WAS Software' CPU costs number.
Observation
The CPU costs for the transactions are nearly half as much for the CEX3 measurement series.
Conclusion
The exploitation of the IBM System z cryptographic features reduces the CPU costs for SSL transactions dramatically. The reduced CPU costs allow more incoming transactions to be processed and a higher transaction throughput rate is possible.
DayTrader average response times
Figure 3 shows the response times reported by the DayTrader benchmark application.
The average response time for a SSL transaction is the amount of time needed to answer a client request. The metric is measured in milliseconds (ms) for the DayTrader benchmark application. Lower numbers mean faster response times.
Observation
The average response times shortens more than 40% when IBM System z cryptographic features are used.
Conclusion
The setups with CEX3 features dramatically improve the response times compared to software encryption. The cryptographic operations can be processed much faster when offloaded to a cryptographic hardware feature. This results in better response times for SSL transactions.