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.