Re: [load balancing] Verisign and Load Balancers

From: Eric Gray (egrayIZZATsitesmith.com)
Date: Tue Feb 20 2001 - 13:05:27 EST

  • Next message: Alex Samonte: "Re: [load balancing] Verisign and Load Balancers"

    On Fri, Feb 16, 2001 at 09:27:37PM -0600, KJ & JC Salchow wrote:
    > There are Rainbow cards which do bulk encryption, the reason most people
    > don't utilize them is because the bulk encryption is generally RC4 which is,
    > by design, built to be fast and efficient as a software implementation -
    > whereas the RSA encryption used in the asymetric key exchange is fast and
    > efficient in straight hardware. If you look at the stages of SSL, the bulk
    > encryption is not difficult or processor intensive - it's essentially a
    > onetime pad cipher - which equates to simple substitution cipher with a
    > unique key at least as long as the message to avoid repitition. This is not
    > tough - programmatically or processor wise. That's what makes PGP such a
    > great system - it uses the RSA for the transmission of the onetime pad
    > cipher and then uses that to perform bacis substitution. Yes, I know this
    > is a little simplified, but its accurate enough to argue the impact of bulk
    > encryption on the processor. If it weren't for the asymetric key exchange -
    > the part everyone is off loading - SSL would have almost no impact on the
    > machine.

    I spoke to Rainbow recently and they indicated that bulk encryption was
    not available in their products. But that might have changed. I am
    aware of efforts to produce hardware bulk encryption by other vendors.

    >
    > As to handling more than 200 conn/s - I've never seen an F5 box that I've
    > worked on or supported at more than 54% processor utilized no matter what
    > they were doing. Most of the real work on the BIG-IP revolves around
    > memory, not processor - and when compared to the other "general purpose
    > processors" I'd much rather have the F5's Pentium III than the ones used by
    > Alteon, Cisco or Foundry. Which brings us back to the SMP. With v4.0 F5
    > will be on the "unified" BSD kernel which will support SMP. And I'm sure
    > I'd rather have dual PIII 890's than anything anyone else has. I also
    > question the 100% processor utilization because most people will test their
    > SSL tps by doing nothing but flooding a box with NEW SSL sessions - NEW
    > sessions means NEW keys which are offloaded to the Rainbow card. I have a
    > hard time believing that the F5 box hits 100% utilization doing nothing buy
    > handing off SSL handshakes.
    >

    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.

    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.

    I am a fan of the BIG-IP, but the SSL solution is not appropriate for
    every site. A separate dedicated group of SSL boxes is much more
    scalable. Of course F5 makes those too.

    Eric



    This archive was generated by hypermail 2b30 : Tue Feb 20 2001 - 13:07:59 EST