RSA key size 4096-bit

Edit online

Results for tests performed for scenario 2 using RSA key size 4096-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 4096-bit RSA key.

Figure 1. SSL transaction throughput when a 4096-bit RSA key is used
Bar graph for transactions in percentages and IFLs used

The green bar and the blue bars (dark) in the diagram show the normalized DayTrader SSL transaction throughput for each considered cryptographic setup. The throughput number for the "IBM WebSphere Application Server (WAS) software" setup (green bar) defines the 100% baseline for the other cryptographic setups.

Observation

The use of CP Assist for Cryptographic Function (CPACF) doubles the transaction throughput compared to a pure software setup. The transaction throughput can be increased by more than five times with one Crypto Express3 (CEX3) processors. When two CEX3 processors of the same type are used, a six times higher throughput rate can be achieved.

Conclusion

When a CEX3 feature is used in the cryptographic setup, the possible transaction rates increase considerably. The selected strong WAS cipher suite together with a RSA key size of 4096-bit require a lot more CPU resources for the cryptographic operations. If the 4096-bit cryptographic operations are calculated completely in software, the available CPU resources are fully used quickly. Hence offloading the cryptographic operations to any IBM® System z® cryptographic features allows much higher transaction throughput rates.

For the '1-CEX3A/C' setups a high pending request count (5-8 requests) can be observed. The maximum pending request queue size for the zcrypt device driver is currently 8. This is an indicator that a single CEX3 processor operates at its limit. Adding a second CEX3 processor (2-CEX3A/C setups) of the same processor type allows a further throughput increase. The zcrypt device driver does a load-balancing over the two available CEX3 processors, which helps to overcome the single CEX3 processor limit in that case.

The second series of bars (yellow/light bars) lists the number of Integrated Facility for Linux® (IFLs) used on the WAS LPAR, where the LPAR is equipped with 4 IFLs in total.

Observation

All 4 CPUs are almost fully loaded for the "WAS Software" and "CPACF" setups. Approximately 3 out of 4 IFLs are used for the 1-CEX3 and close to 4 IFLs for the 2-CEX3 setups.

Conclusion

For the setups with IBM System z cryptographic features, CPU time is freed because cryptographic operations are offloaded to the cryptographic features. The freed CPU time can be used to handle a larger amount of transaction requests compared to the "Software" setup.

One CEX3 processor is fully used in the '1-CEX3' setups, almost sextupling the transaction throughput compared to "Software"'. It is the limiting resource in that case.

A second CEX3 processor helps to overcome the single CEX3 processor limit and nearly all 4 IFLs are now used.

Daytrader transaction CPU costs

Another important aspect with respect to the throughput numbers reached is the amount of CPU required to satisfy the workload, which is considered as 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 4096-bit RSA key is used.

Figure 2. CPU costs for SSL transactions when a 4096-bit RSA key is used
Bar graph showing CPU cost for RSA key 4096 bit

The chart shows the CPU costs for the SSL transactions when using a 4096-bit RSA key. The numbers are normalized against the "WAS Software"' CPU costs number.

Observation

The usage of System z cryptographic features is reducing the CPU costs for SSL transactions. For the setups including CEX3 features, the CPU costs for transactions are reduced by more than factor six.

Conclusion

The exploitation of the System z cryptographic features reduce the CPU costs for SSL transactions dramatically. The reduced CPU costs allow to process more incoming transactions and hence a higher transaction throughput rate is possible.

DayTrader average response times

Figure 3 shows the response times reported by the DayTrader benchmark application.

Figure 3. Average response times for the SSL transactions when a 4096-bit RSA key is used
Bar graph showing the average response times

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 time is about 5 ms for the measurement series with CEX3 features. Whereas the average response time for the "WAS Software" setup is over 20 ms.

Conclusion

The cryptographic setups with CPACF and CEX3 features provided the best response times in our setup. Any cryptographic operation can processed much faster when offloaded to a cryptographic hardware feature. This results in considerably better response times for the applications running on a WAS server.