There are 2 things which come to mind when you're talking about ssl
performance testing. They are: 1. the number of keysigns/sec that a single
server can do without ssl acceleration, and 2. the performance bottlenecks
of the system being tested under HTTPS load.
I've done several hundred million hits worth of testing, which by the way
is a lot and takes a long ass time, no matter if you have an ssl accelerator
card or not. Our company uses LoadRunner, a commercially available product
which costs a LOT of money. You could also use httperf, available over at
www.freshmeat.net.
1. Key Signs/sec. : a good measure of pure processing power, bus i/o, and
memory subsystem.
2. Performance Bottlenecks:
A. Disk I/O - if you have a lot of log writing going on, it will hinder your
ssl performance. Put all your logs into one file, or even on an entirely
other disk to help aleviate this if you REALLY need them, otherwise a
symlink to /dev/null will help. (access_log has everything anyway)
B. SSI's - server side includes can incur extra processing time on top of
SSL, and this of course, will increase your latency. SSI's in conjunction
with SSL can hurt under HIGH volume.
C. Key length - Obviously, the longer the key, the greater the processing
power needed, the longer the key takes for the handshake, and again your
latency is affected. Stay away from DSA keys (2048-bit)! :)
D. CGI's vs Modules - unless you're using a fcgi, standard cgi's will eat
your lunch too. The reason being that you are calling a file, something has
to then be executed on the system to deliver an output(writing to a socket,
which apache is handling) then you must log that transaction, and since it's
ssl, most systems will maintain persistence.Thus, leading back to file I/O,
and if you have a bunch of logs on the same filesystem, then you just
increased your latency. (use /dev/null if you don't know how to turn off
your logs). Modules on the otherhand skip some of those steps, as well as
FCGI, so your file I/O is a bit aleviated.
E. No KeepAlive - If no keep alive is used, then it is in fact highly
possible to INCREASE your latency, because you are now forcing handshakes
over and over, and over, and over, so game's over. On the other hand if your
data is not that persistent to begin with, then you will benefit by turning
off keep alive. Say a module is called from apache, some data is streamed in
or out, and then the connection is closed. No worries there.
That's about it. Take into account these things and what your end goal is
supposed to be, and you will be able to properly test your systems. These
things are also important when talking about using a loadballanced farm. If
you have more questions I'll be happy to answer them.
Austin
-----Original Message-----
From: Corinne Dive-Reclus [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 27, 2000 10:00 AM
To: '[EMAIL PROTECTED]'
Subject: benchmark
Hello,
I am quite new in the world of SSL so I hope this newsgroup is the
relevant
one. I would like to measure the number of SSL connections my Web server
can
reasonnably perform and I am looking for a SSL client application that
can
generate loads of SSL handshakes. I wonder if such application has been
already written using mod_ssl ( or something else I do not mind). If a
binary version exists ( Solaris or WinNt4) it will be even better but
otherwise I will be ready to compile some source code.
Thanks for your help.
Corinne Dive-Reclus, Principal Software Engineer
Baltimore Technologies, Focus 31, West Wing,Cleveland Road, Hemel
Hempstead,
Hertfordshire, HP2 7BW, England
Tel: +44 (0) 1442 342600 Fax: +44 (0) 1442 347399
E-mail [EMAIL PROTECTED]
Website <http://www.baltimore.com/>
Baltimore - Global e-Security
The information contained in this message is confidential and is
intended
for the addressee(s) only. If you have received this message in error
or
there are any problems please notify the originator immediately. The
unauthorised use, disclosure, copying or alteration of this message is
strictly forbidden. This message and any attachments have been scanned
for
viruses. Baltimore Technologies plc will not be liable for direct,
special,
indirect or consequential damages arising from alteration of the
contents of
this message by a third party or as a result of any virus being passed
on.
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
