From: Alex Samonte (asamonteIZZATprison.net)
Date: Wed Sep 04 2002 - 14:14:13 EDT
On Wed, Sep 04, 2002 at 07:43:16AM -0700, shawnIZZATnunleys.com 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
> > 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 www.vegan.com, 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
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
> > 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
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: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2.1.4 : Wed Sep 04 2002 - 14:20:52 EDT