Subject: RE: Apache-modSSL performance problems

From: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <[email-masked]>
Date: Sat, 2 Mar 2002 10:22:57 -0800

just iterating on point (a) mentioned by Geoff, if you force the negotiation
using RC4 (which I believe is forced by iPlanet), you should see a
substantial increase in the no. of connections handled.. The other
parameters (logging etc) does help, but not as much as (a)..

BTW, as a seperate question, why is RC4 not made the default crypto to be
used in mod_ssl ?.

-Madhu

-----Original Message-----
From: Geoff Thorpe [mailto:[email-masked]]
Sent: Friday, March 01, 2002 9:31 PM
To: [email-masked]
Subject: Re: Apache-modSSL performance problems

Hi there,

I can recommend trying "swamp" for testing your servers, but that is (of 
course) a take-it-or-leave-it tip, no strings attached.

   http://www.geoffthorpe.net/crypto/swamp/

However, the README/FAQ files in that contain quite a bit of information on 
this subject that will help you if you read them. But let me throw you the 
relevant words, and allow you to work through them (and the information 
files) at your leisure;

(a) cipher suites (esp. "EDH")
(b) session caching (what resume behaviour are you getting on iplanet 
versus modssl?)
(c) configuration (default config with modssl is not heavily optimised, eg. 
SSLLogLevel, "mime magic", "CompatEnvVars", etc may slow things down).

Cheers,
Geoff

On Saturday 02 March 2002 12:31, Latif, Magid wrote:
> Greetings all,
>
> I noticed a posting to the modssl-users list concerning performance
> figures of Apache-modSSL. I was wondering if you've came across any
> information in that regard. I am getting quite bad performance with
> apache-modSSL on a SPARC Solaris 8 platform.
> Iplanet is achieving 98 hits/second with versus 6.8 hits/second with
> apache-modssl on average.
> I am using a very simple test scenario using LoadRunner 7.02. See tests
> details below :
>
> Background:
> -----------
> During performance tests I discovered a severe performance problem with
> Apache-modssl. The versions subjected to the tests were :
>
> Test Versions:
> -------------
> apache-1.3.19-modSSL-2.8.3 without MM file-based SSL session caching.
> apache-1.3.19-modSSL-2.8.3 with MM and shared memory based SSL session
> caching.
> apache-1.3.23-modSSL-2.8.6 with MM and shared memory based SSL session
> caching.
> iplanet 6.0sp1-128bit - default (out of the box) configuration
>
> Test Platform:
> --------------
> Webserver : SPARC Solaris 8 10/01 with latest patches installed
> Load generator: Pentium III 512MB, win2k, LoadRunner 7.02 - Emulating IE
> 5.5
>
> Test Scenario:
> --------------
> I created a simple load test scenario using LoadRunner. (version 7.02 on
> a 512MB PIII w/win2k) The scenario consists of accessing three static
> HTML pages. Those pages contain no images. Running the scenario with 3
> concurrent users (loadrunner virtual users) resulted in the following :
>
> Test Results:
> -------------
> + apache-1.3.19-modSSL-2.8.3-openSSL-0.9.6a without MM - Concurrent
> Users: 03
>     Running time   : 11 minutes
>     Hits/Second    : 4.72 (average)
>     Webserver load : 3.2 (average)
>
> + apache-1.3.19-modSSL-2.8.3-openSSL-0.9.6a with MM - Concurrent Users:
> 03 Running time: 11 minutes
>     Hits/Second : 6.57 (average)
>     Webserver load : 3.2 (average)
>
> + apache-1.3.23-modSSL-2.8.6-openSSL-0.9.6c with MM - Concurrent Users:
> 03 Running time: 11 minutes
>     Hits/Second : 6.79 (average)
>
> + iplanet 6.0sp1-128bit - Concurrent Users: 03
>     Running time: 11 minutes
>     Hits/Second : 98.2 (average)
>     Webserver load : 4.2 (average)
>
>
> I turned off modSSL within the same apache configuration and increased
> the number of concurrent users in LoadRunner to 90. This resulted in a
> bit more than 170 hits/second. Therefore, I concluded that modSSL is
> having some severe performance problems.
>
> Perhaps I am missing some tuning parameters specific for modSSL ?
>
> Any input very welcome.
>
> Cheers,
>
> Magid.
>
> =================================
> Magid Latif
> Systems Engineer
> iPIN
> 19 Davis Drive
> Belmont, CA 94002
> Direct: +1 (650) 232 3704
> Main:   +1 (650) 232 3700 x3704
> Fax:    +1 (650) 232 5116
> http://www.iPIN.com
>
>
> =====================================================================
> Warning:  All e-mail messages sent to or from this address are recorded
> by the iPIN corporate e-mail system and may be subject to archival and
> review. Furthermore, information in this e-mail may contain privileged or
> confidential information and is intended only for the recipient.  If you
> receive this message in error, notify iPIN immediately by replying to
> this message and then deleting it from your computer.  Any information in
> this e-mail doesn't necessarily reflect the views or opinions of iPIN.
> ====================================================================.
>
>
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
> User Support Mailing List                      [email-masked]
> Automated List Manager                            [email-masked]

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Geoff Thorpe <[email-masked]>
Date: Sun, 3 Mar 2002 11:27:58 +1300

Hey there,

On Sunday 03 March 2002 07:22, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
wrote:
> just iterating on point (a) mentioned by Geoff, if you force the
> negotiation using RC4 (which I believe is forced by iPlanet), you should
> see a substantial increase in the no. of connections handled.. The other

Yep, quite likely.

> BTW, as a seperate question, why is RC4 not made the default crypto to be

https (and thus modssl) exist to give strong security to the carriage of 
http data. If security wasn't an issue, you'd simply use http and have 
substantially better performance (CPU, network, caching, etc). So, it makes 
sense for the order of supported SSL/TLS cipher-suites, as exposed by the 
server anyway, to be based on security considerations rather than speed.

I.E./Netscape etc don't support EDH cipher-suites, nor many other oddball 
ones for that matter, so this isn't a "problem". But, if the browser 
expresses support for them, it makes sense for the *default* (in lieu of 
any settings/overrides by the server-admin or browser-user) to be the most 
secure choice. EDH suites have Perfect Forward Secrecy, which from a 
security point of view is much better than other (faster) suites without 
that property.

If speed is the issue, then that changes things - but the server shouldn't 
assume that focus for the user/admin by default - it is a *security* module 
after all. A benchmarking program for https support should make it clear in 
docs and/or command-line usage how it deals with cipher-suite selection. It 
makes a big difference to the type of security being used, and the 
CPU/bandwidth requirements of the SSL/TLS negotiation at either end (eg. 
consider the difference between DSA and RSA on the bias of workload between 
client and server!). Typically people only think about the speed, never 
give a moment's thought to the security (which is odd given they're 
installing https support), and don't even pay attention to which cipher 
suite is being used when *measuring* the speed.

Read: a crap SSL/TLS server can fool you into thinking its better than a 
full-grade security module for apache with all the trimmings, simply 
because it refuses to support higher-grade security parameters from the 
outset. Security is not a rubber stamp - nor a padlock icon in the browser 
window. A server that thinks any cipher-suite is "good enough" *for* the 
admin rather than letting the admin specify that if it is so, is 
programmed/designed by anyone *except* the security savvy.

Cheers,
Geoff