On Wed, Jan 16, 2002 at 11:28:48PM -0500, Steve Birnbaum wrote:
> > -We've done some rudimentary load-testing with our boxes. We put
> > about 150 sustained ssl connections through a pair of SCA's running
> > 3.0.5 code. Under that load, each SCA bounced between 20-40% cpu.
> This isn't really testing what SSL accelerators are designed for. Most
> use hardware acceleration only for the intensive asymmetric encryption
> and let the main CPU handle the symmetric crypto. Boxes that can only
> handle 100 new RSA handshakes per second could easily sustain a few
> hundred DES/3DES connections pushing a few bytes through.
> In fact, 150 sustained connections sounds to be pretty terrible given
> that almost a year ago when I was rather heavily involved in that
> industry, the market leaders were pushing over 600 new connections per
> Just a heads-up for anyone performance testing SSL accelerators. Make
> sure that your test tool is not performing SSL session resumptions
> unless you want it to. I found at least one tool that claimed to be
> making new RSA handshakes when in fact it was just doing session
> resumptions based on cached SSL session IDs. The performance numbers
> with that test tool were needless to say, quite good. Also most vendors
> test while requesting a 0 byte file using a low-grade cipher. The hit
> of having to do symmetric crypto on the main CPU to actually transfer
> data rarely linear.
We have done plenty of testing with SSL accelerators, and while it is true
the current set of SSL accelerators only deal with the handshake, the bulk
encryption is nothing to laugh at either.
There is a big difference in the performance curves in checking the number of
ssl connections/sec with 0 or near 0 length files, and when doing the same
test with even a 10K or 40K file. The bulk encryption does make a
The bulk encryption is still a task to be performed, and if that's not
accelerated, the SSL accelerator has to do it with its general purpose
CPU. And that can get maxed out. If the SSL accelerator is doing
other tasks those suffer. For example if you had the SSL card in the
LB (like F5) doing 180 conn/sec will make the F5's cpu spike up near 100%
(depending on speed of cpu). This obviously impacts it's ability to deal
with http traffic as well.
Fortunately the newest generation of SSL chips generally also handle the bulk
encryption as well. This will hopefully make it less of a concern.
The Load Balancing Mailing List
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2b30 : Thu Jan 17 2002 - 13:46:04 EST