On Tue, Feb 20, 2001 at 05:43:57PM -0600, KJ & JC Salchow wrote:
> ----- Original Message -----
> From: "Eric Gray" <egrayIZZATsitesmith.com>
> To: <lb-lIZZATvegan.net>
> Sent: Tuesday, February 20, 2001 12:05 PM
> Subject: Re: [load balancing] Verisign and Load Balancers
> > Recently, I did this very thing in our lab. I was able to get about 210
> > conn/sec, at which point the CPU is saturated.
> I wasn't trying to knock on Alex about this - I said I'd never seen it.
> What interests me about this is that my understanding - at least of the F5 -
> was that the card was rated at 200 tps, and even F5 admits that you'll never
> see that. But additionally, I understood that anything over that tps, the
> F5 would simply drop the requests. What your numbers almost say is that
> once the Rainbow card has been saturated, the F5 doesn't drop the packets,
> but attempts to handle the DH exchange all by itself. That would definetly
> kill the CPU. I could understand if that was what was happening - as I
> never liked the "drop the packet" answer myself, so maybe they changed it to
> handle "flash" traffic?
Hard to say if all the requests not processed by the cryptoswift go to
the CPU. That would be bad. In this test with fewer clients we
observed 141 conn/sec and 51% CPU utilization. So what that tells me is
that even if the cryptoswift is not maxxed, there is still significant
CPU usage. If we don't expect this to scale linearly, then this seems
okay. Otherwise, there is more room for testing.
> > The load client I used was http_load compiled with OpenSSL. It does not
> > cache or reuse sessions, so each request is a new one. The file
> > requested was less than 1k.
> Whew! Good thing you weren't testing throughput :-)
Right, we purposely chose a small file to test conn/sec vs. throughput.
[I don't see this as trying to knock on anyone. We're all just trying to
share information and opinions.]
This archive was generated by hypermail 2b30 : Tue Feb 20 2001 - 20:05:00 EST