Re: [load balancing] Help in shoosing an SSL accelerator.

From: Alex Samonte (
Date: Wed Sep 04 2002 - 14:14:13 EDT

  • Next message: Alex Samonte: "Re: [load balancing] Help in shoosing an SSL accelerator."

    On Wed, Sep 04, 2002 at 07:43:16AM -0700, wrote:
    > Alex Samonte wrote:
    > >
    > > Compression is also part of the HTTP spec.
    > Compression for HTTP is also mostly turned off (or not turned on) because of CPU
    > impact.
    > > The type of data most real world things use HTTPS for are fairly small
    > > anyway. Usually data for part of a secure transaction. The fact that
    > > you can compress it in my opinion is not a big gain.
    > Believe it or not, huge gains can be realized by utilizing compression with both
    > HTTP and HTTPS. The problem has historically been that the gains were not worth
    > the added CPU (read more servers) that were required to make it work,
    > As an example, If I load, the first page I get is 48,161 bytes.
    > It takes 58 packets to transmit that page to me. The total download time (time
    > Now, with compression enabled, that same page downloaded through NetScaler is
    > only 9324 bytes, an 81% reduction. The number of packets required to transmit
    > it is only 17, a 71% reduction. The total download time is reduced to 3.346
    > seconds.

    I didn't say compression isn't effective. I said HTTPS compression was
    not a big gain. HTTPS sessions are generally much smaller due to their
    transactional nature.

    > > Even compression in the HTTP area is only real world useful (meaning has
    > > good tangible benefits on b/w usage) for news, or other heavily text
    > > based sites.
    > The point about compression and SSL was to show that doing SSL alone is not
    > enough to meet the performance demands/expectations of users. Encrypted data,
    > as you know, is not compressible. So, when not compressed, encrypted traffic
    > that flows to a user over a modem cannot be helped by modem compression. Modems
    > transparently compress traffic in order to allieviate that last mile bandwidth
    > bottle neck. When the data is compressed before encryption, we see many
    > benefits, including faster transmission to users.

    And my point is you're not comparing apples and oranges. you're talking
    about compression features outsite of the SSL accelerator question the
    original post was about.

    Here's a question about compression and SSL though.

    Are you doing the compression to the client, server or both?

    Compression to the server would be simple, and actually a non HTTPS way
    of doing things.

    client <---SSL---> netscalar <--nonSSL+compression--> server

    That could be achieved by any SSL + LB combo where the LB supported

    client <--SSL+compression--> netscalar <--nonSSL+noncompression--> server

    would seem to be more difficult since you would have to remangle the
    content before encrypting it.

    most SSL + LB combos would not be able to do this unless they were
    acting like a full proxy (which your box does). Since you fully
    terminate the IP and SSL connection at your box, while most other boxes
    do the 'delayed bind' method, and 'transparent' SSL.

    > - less packets sent to users means less load on your infrastructure
    > - bandwidth utilization drops dramatically
    > - percieved latency drops
    > - perforance is on par with plain HTTP

    I disagree with these assertions when you are talking about HTTPS. Just
    because the requests are already small to begin with.

    In a day where everythig can be made SSL enabled for no cost, then these
    benefits will definately apply in most cases, and not niche cases.
    I used to be a big believer in full SSL conversion. One of the main
    reasons I'm not any more is the economy. No one has the money to buy
    the infrastructure to make full SSL enabling a reality. For now it will
    be on a case by case basis. Also with some more thought about how
    certain things work with and without SSL, it's not quite as simple as
    'just turning it on'. How some sites are built will not be able to work
    with just changing http:// to https:// becuase of things like forign
    banner/image linking, the ability for users to save pages, etc. It
    won't be as simple as turning on a lightswitch.

    > > These things are not necessary for a SSL accelerator. Most of this
    > > functionality is in the load balancer portion of whatever equipment they
    > > are using.
    > > pieces. A LB piece, and a SSL piece. It may not be how you view your
    > > product, but it's how i do, and I feel the best way to explain this
    > > stuff.
    > We do view them as one, but then we are ahead of the curve. I understand your
    > position.

    Not ahead, you've just combined existing functionality into a single
    box. You are not the first to do so.

    > > If the cost approaches zero, but right now that's not the case.
    > The price certainly is coming down for SSL (per TPS anyway). Our goal is to see
    > sites just use SSL for the whole site, and not have to sacrifice performance to
    > do it. Until now, I haven't seen an acceptable way to do it. Sites that *had*

    but the point is since you need to talk about 'price per tps' then I
    know the price isn't low enough. I don't want to have to talk about
    that at all.

    When the price of a SSL and non SSL version of the product (anyone's not
    just yours) is the same or near the same, then it will be something easy
    for a site to 'just turn on'. For now it's really separate
    functionality most people will only pay for if they are sure they need


    The Load Balancing Mailing List
    MRTG with SLB:
    Hosted by:

    This archive was generated by hypermail 2.1.4 : Wed Sep 04 2002 - 14:20:52 EDT