Threads | Compression
SSL
In WebSphere Commerce systems, Web servers are typically SSL endpoints. SSL handshakes, encryption, and decryption therefore add significant overhead over IBM HTTP Server's processing.
As WebSphere Commerce makes extensive use of SSL, IBM recommends using multiple remote Web servers on dedicated machines. Also, in WebSphere Commerce, once a user has signed in or added anything to his shopping cart, many pages will be requested using HTTPS, so limiting encrypted content is not an option.
WebSphere Commerce instance creation configures IHS to use the module mod_ibm_ssl for SSL processing. The following two directives are relevant for performance:
- SSLV2Timeout and SSLV3Timeout
The SSL sessions should live slightly longer than the typical user session, to avoid too many change cipher suite handshakes. Keepalive settings have no effect here. The length of the typical user session can be determined by analyzing the Web server access log.
- SSLCipherSpec
Encryption algorithm used by SSL. The client browser and IHS server negotiate the algorithm to be used by attempting to use the strongest algorithm in its list, then walking down the list until the algorithms match. Different encryption routines have widely varying rates of CPU consumption, for example, Triple DES uses vastly more cycles than RC4.
To save processing time, you could therefore set the crypto list in the server to favor RC4 with MD5
<VirtualHost ...> ... SSLEnable ... # RC4 with MD5 for SSL V2 SSLCipherSpec 21 # RC4 with MD5 for SSL V3 SSLCipherSpec 34 ... </VirtualHost>