Hi there,
On Tue, 9 Jan 2001, Mads Toftum wrote:
> > I have these settings in my httpd.conf:
> >
> > SSLSessionCache dbm:/www/secure_apache/logs/ssl_scache
>
> Whoa there! Why do you have dbm for your session cache, when you
> compiled with mm support? It should be set to shm (especially on
> Solaris which has fairly decent shm support) - see
> http://www.modssl.org/docs/2.7/ssl_reference.html#ToC5
Or compile in support for shmcb (which it just so happens I wrote because
shm is not very fast) :-) Of course this is to make fast heavy-load
servers go a little bit faster and heavier, but this doesn't stop
ridiculously slow servers from dragging their heels ...
> > SSLRandomSeed startup builtin
> > SSLRandomSeed connect builtin
>
> You could go for the full /dev/urandom support from Sun - see the
> thread from today on openssl-users about Solaris prng:
> http://marc.theaimsgroup.com/?t=97872512100003&w=2&r=1
You can see if it's a randomness problem simply by using a large binary
file (doesn't really matter what) ... just specify that as a source of
randomness at "startup" and "connect" - this is a BAD idea in production
of course, but will at least help you diagnose where your system is
getting stuck ... it will simply assume your large binary file as it's
source of entropy and so won't be looking elsewhere (which could be your
slow-down).
> > which I have read to be the problems in others instalations but do not
> > appear so in mine (they are the default). The only odd thing about this
> > install is that the total partition is NFS mounted. However, this doesn't
> > seem to be a problem with our other non-mod_ssl installation of apache.
> > Any thoughts or ideas would be greatly welcomed. Thanks, and have a nice
> > day.
> >
> Is your SSLSessionCache dbm file from above placed on nfs? That could definetely
> explain why you get lousy performance.
Indeed. Make that cache local ... or stick it in shared memory. This might
explain why your CPU load looks low ... it's not that the system is busy,
it's just that the dbm-over-nfs stuff has a high latency (especially if
your dbm file is big).
> There is a short paper on SSL performance which compares a couple
> of different processors ... and the Sparc's is not a real preformance
> winner ;-) http://www.awe.com/mark/apcon2000/apachecon2000.pdf
Thanks for the plug :-) (I co-wrote that paper).
In fact although the shmcb cache was written to slice off the overheads
shmht has (session caching should be *zero* overhead compared to RSA/DSA
cryptography but shmht was adding up to 20% at times, depending on your
angle of attack). But the other reason for shmcb was that shmht is not
suited at all to concurrency - there's no obvious way how to slice it up
to use multiple mutexes (so there's no single global lock in use). Ie. the
idea of a session cache server in that paper requires something more like
shmcb than shmht. Having said all that shmcb still uses a single global
lock, but that's because I couldn't be bothered going the extra step and
adding new directives to enable multiple mutexes :-) (Ralf?? do you feel
game to try??)
Another thing to try - restrict your ciphers. How you do this will depend
on how you're testing, but if you're testing using a dedicated client
program (rather than say a web-browser) then it could be that your SSL
connections are settling on EDH cipher suites which are (a) a lot more CPU
work, and (b) use up a lot more entropy (hence pushing the PRNG harder).
If you know the list of ciphers your client supports then set the
SSLCipherSuite (doing this from memory, check the directive name and
syntax from the docs) to just one cipher suite to force what gets
negotiated in the handshake ("RC4-MD5" or "RC4-SHA" are good if your
client supports them). Again, this isn't a great idea for production but
at least helps in diagnosis. The other trick would be to take the default
cipher list but to "-EDH" or whatever the syntax is to rule out the
ephemeral suites - this *would* be a good idea in production if EDH is too
much workload for your system.
Hope those ideas help ... the next step is to offer remote shell access to
someone else to go in and take a look :-)
You are just requesting a static HTML page right??
Cheers,
Geoff
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
