Chris Komuves' Guide to Performance Tuning Apache SSL for Solaris

After much frustration at the poor out-of-the-box SSL performance I was getting with Apache, verses the iPlanet 6.0 webserver I was also running, I decided to see just how much I could optimize Apache to improve performance. I like Apache a lot more than iPlanet (now called Sun ONE), since there are not lots of slow Java-based GUIs standing in-between me and configuring the application, and in my experience, there have been fewer bugs with Apache. So, after careful tweeking and testing, here are my suggestions for how to get the best possible performance out of Apache SSL on Solaris 9. Most of these suggestions are applicable to other systems as well. I plan on updating this page with more complete information, better benchmarks, and future versions of Apache when I have time.

After great effort, the result was an Apache configuration that is only a little slower than iPlanet, and certainly fine for low and medium scale webservers. For high-volume webservers, it appears as though one could get better performance with the Sun ONE Web Server (formerly iPlanet, formerly Netscape Enterprise), or perhaps substantially better performance with Zeus. Also, an SSL acceleration card, like Sun[]tm] Crypto Accelerator 1000 could help greatly when using any Webserver that is supported by it.

Before I began my testing, I performed a somewhat crude benchmark of the performance of Apache (with the MPM worker module) verses iPlanet 6, running a CGI-heavy test suite on a Sun Fire 280R. My results were

Server	Avg. Response Time Seconds	Transaction Rate/Second	CPU Max %	Notes
Apache	0.130	19.20	2.8
iPlanet	0.153	19.67	1.5	>200 failed trans
Apache SSL	1.615	2.18	24.0
iPlanet SSL	0.255	12.88	7.9

To improves performance, here are the steps to take.

1. Disable 3DES encryption. This makes by far the largest improvement in performance. Most browsers support both 3DES and RC4-128, but will use 3DES if it is available. 3DES can be several times as slow as RC4-128. Here is the same test performed with just this change. Change to the following line in your httpd.conf or ssl.conf file.

   SSLCipherSuite !ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

   With just this single change, the performance when repeating the same test above was as follows!

   Server	Avg. Response Time Seconds	Transaction Rate/Second	CPU Max %	Notes
   Apache SSL	0.180	10.29	15.0



2. Make the SSL session cache longer. Depending on your usage patterns, this may or may not be helpful. Change to the following line in your httpd.conf or ssl.conf file.

   SSLSessionCacheTimeout  900



3. Switch from using a DBM file to store the cache to using a shared memory cyclic buffer (this eliminate disk I/O). Change to the following line in your httpd.conf or ssl.conf file.

   SSLSessionCache         shmcb:logs/ssl_scache(512000)



4. Change the accept() mutex method Apache uses to POSIX thread mutexes (pthread). Change to the following line in your httpd.conf file.

   AcceptMutex pthread



5. Change the SSLMutex to use POSIX thread mutexes (pthread). Change to the following line in your httpd.conf or ssl.conf file.

   SSLMutex pthread



6. Take out any unused modules. For instance, provide the following to the configure command.

   --disable-userdir --disable-imap



7. For Solaris on UltraSPARC, compile it to make more efficient use of the UltraSPARC processor (which will prevent it from running on old SPARC processors),\ using the following argument to configure.

   --enable-nonportable-atomics=yes



8. Provide /dev/urandom as an additional source of random numbers (don't remove the existing builtin sources, as this can cause problems). Add the following lines in your httpd.conf file.

   SSLRandomSeed startup   file:/dev/urandom 512
   SSLRandomSeed connect   file:/dev/urandom 512

After all of these changes and additional testing, I created a more stable benchmark, consisting of random accesses by 4 concurrent users to a set of URLs consisting of 1,000 CGI-generated pages plus 1,000 instances of a page that used server-side includes, run for 1 minute using Siege. CPU Max % is approximate, and iPlanet hides much of it's usage through separate Cgistub processes that wasn't included. Test was run from a machine on the same LAN as the server, over a 100 Mbps network, to minimize network latency.

So, overall, for a CGI-intensive webserver (after all, isn't that usually the type on which you would want to run SSL?), I could get Apache to serve up SSL-encrypted Web pages about 15% slower than iPlanet, and handle about 88% of the load that the same server with iPlanet could. Not bad at all for most applications.