The following are two types of Secure Sockets Layer (SSL) performance:
When an SSL connection is established, an SSL handshake occurs. After a connection is made, SSL performs bulk encryption and decryption for each read-write. The performance cost of an SSL handshake is much larger than that of bulk encryption and decryption.
Using a single SSL connection to send multiple requests (rather than opening a connection for each request) can enhance SSL performance. Additionally, it is important to reduce the the number of times a new connection is opened. Decreasing the overall number of connections increases performance for secure communication through SSL connections, as well as non-secure communication through simple TCP/IP connections. One way to send multiple requests over a single SSL connection us to use a browser that supports HTTP 1.1.
Another common approach is to decrease the number of connections (both TCP/IP and SSL) between two WebSphere Application Server components. The following guidelines help to verify the HTTP transport of the application server is configured so that the Web server plug-in does not repeatedly open new connections to the application server:
Verify that the maximum number of keep-alives are, at minimum, as large as the maximum number of threads supported by the Web server. Make sure that the Web server plug-in is capable of obtaining a keep-alive connection for every possible concurrent connection to the application server. Otherwise, the application server closes the connection after a single request is processed. Also, the maximum number of threads in the Web container thread pool should be larger than the maximum number of keep-alive connections, to prevent the keep-alive connections from consuming the Web container threads. For more information about this setting, see Example: Setting custom properties for an HTTP transport.
Consider increasing the maximum number of requests per keep-alive connection. The default value is 100, which means the application server closes the connection from the plug-in after 100 requests. The plug-in then must open a new connection. The purpose of this parameter is to prevent denial-of-service attacks when connecting to the application server and preventing continuous send requests to tie up threads in the application server. See Example: Setting custom properties for an HTTP transport for more information about this setting.
Use a hardware accelerator if the system performs several SSL handshakes.
Note: The IBM Cryptopgraphic Coprocessor for iSeries is not supported for use with WebSphere Application Server. However, you can use the IBM Cryptographic Coprocessor to improve SSL performance for other iSeries products, such as IBM HTTP Server for i5/OS (powered by Apache).
An accelerator typically only benefits the Web server because Web server connections are short-lived. Generally, WebSphere Application Server connections are more long-lived, so using a hardware accelerator does not significantly improve SSL performance for WebSphere Application Server.
Another way to improve performance is to use an alternative cipher suite that more quickly encrypts and decrypts data.
The performance of a cipher suite is different with software and hardware. Just because a cipher suite performs better in software does not mean a cipher suite performs better with hardware. Some algorithms are typically inefficient in hardware (for example, DES and 3DES), however, specialized hardware can provide efficient implementations of these same algorithms.
The performance of bulk encryption and decryption is affected by the cipher suite used for an individual SSL connection. The following chart displays the performance of each cipher suite:
The test software for calculating the data uses Java Secure Socket Extension (JSSE) for both the client and server software, which uses no cryptographic hardware support. The test did not include the time for establishing a connection, but only the time to transmit data through an established connection. Therefore, the data reveals the relative SSL performance of various cipher suites for long running connections.
Before establishing a connection, the client enables a single cipher suite for each test case. After the connection is established, the client measures how long it takes to write an integer to the server and for the server to write the specified number of bytes back to the client. Varying the amount of data has negligible effects on the relative performance of the cipher suites.
An analysis of the above reveals the following analysis:
Bulk encryption performance is only affected by what follows the WITH in the cipher suite name. This is expected since the portion before the WITH identifies the algorithm used only during the SSL handshake.
MD5 and SHA are the two hash algorithms that are used to provide data integrity. MD5 is 25% faster than SHA, however, SHA is more secure than MD5.
DES and RC2 are slower than RC4. Triple DES is the most secure, but the performance cost is high when using only software.
The cipher suite providing the best performance while still providing privacy is SSL_RSA_WITH_RC4_128_MD5. Even though SSL_RSA_EXPORT_WITH_RC4_40_MD5 is cryptographically weaker than RSA_WITH_RC4_128_MD5, the performance for bulk encryption is the same. Therefore, as long as the SSL connection is a long-running connection, the difference in the performance of high and medium security levels is negligible. It is recommended that a security level of high be used, instead of medium, for all components participating in communication only among WebSphere Application Server products. Make sure that the connections are long running connections.