Use this page to learn about Secure Sockets Layer (SSL)
performance tips. Be sure to consider that performance issues typically
involve trade-offs between function and speed. Usually, the more function
and the more processing that are involved, the slower the performance.
The following are two types of Secure Sockets Layer (SSL) performance:
- Handshake
- Bulk encryption and decryption
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.
To enhance SSL performance, decrease the number of individual SSL
connections and handshakes.
Decreasing the number of connections increases performance for
secure communication through SSL connections, as well as non-secure
communication through simple Transmission Control Protocol/Internet
Protocol (TCP/IP) connections. One way to decrease individual SSL
connections is to use a browser that supports HTTP 1.1. Decreasing
individual SSL connections can be impossible if you cannot upgrade
to 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 reopen new connections to the application
server:
- Verify that the maximum number of keep alives are, at minimum,
as large as the maximum number of requests per thread of the Web server
(or maximum number of processes for IBM® HTTP
Server on UNIX®). 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 alives, to prevent
the keep alive connections from consuming the Web container threads.
Note: HTTP
Transports have been deprecated. For instructions on how to set a
maximum keep alive value for channel based configurations, see
HTTP transport channel settings.
- Increase 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
has to 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.
- Use a hardware accelerator if the system performs several SSL
handshakes.
Hardware accelerators currently supported by WebSphere Application Server only increase
the SSL handshake performance, not the bulk encryption and decryption.
An accelerator typically only benefits the Web server because Web
server connections are short-lived. All other SSL connections in WebSphere Application Server are long-lived.
- Use an alternative cipher suite with better performance.
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 will perform better with hardware. Some algorithms
are typically inefficient in hardware, for example, Data Encryption
Standard (DES) and triple-strength DES (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
calculating the data was Java Secure
Socket Extension (JSSE) for both the client and server software, which
used no cryptographic hardware support. The test did not include the
time to establish 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 times 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 had negligible
effects on the relative performance of the cipher suites.

An analysis of the above data reveals the following:
- 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 Secure Hash Algorithm (SHA) are the two hash algorithms
used to provide data integrity. MD5 is generally 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.