tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Compression and SSL
Date Mon, 02 Nov 2009 20:10:22 GMT
Hash: SHA1


On 11/2/2009 11:48 AM, Jeffrey Janner wrote:
> We encrypt everything using SSL, from Login page onward, with
> <transport-guarantee> of CONFIDENTIAL. 


> Response time is noticeably slow (based on complaint level) and I am
> looking for ways to improve it.

The real question is: how much slower is it than non-secure HTTP? If the
answer is "a lot slower", then you should focus your efforts on
improving the SSL performance. Here are some suggestions in that vein
(from most significant to least, IMO):

1. [Per Pid] Get a bigger machine. More CPU cycles are always helpful
2. Get an SSL accelerator board/appliance. That's what they're there for
3. Switch architectures to something that is better. This is getting to
be hard to do since it looks like x86 and x86-64 are pretty much going
to be the way of the future. My experience in the past was that a single
Sun server could handle a significantly higher load more quickly than
(roughly) equivalent CPU x86 horsepower.
4. Choose a simpler SSL cipher. Some ciphers take much more CPU than
others. Similar to #3, this is less likely to be useful, as simpler
ciphers suck, which is why they are faster :)

If compressing HTTP-only traffic yields a significant improvement, then
go ahead and compress your HTML.

> Will setting the HTTPS connector "compression=on" actually compress the
> data for HTTPS?

Any reason to suspect it wouldn't?

> Does it compress before or after applying the encryption?

HTTPS is defined to be HTTP-over-SSL which means that the encryption is
preformed on the whole connection. So, your HTML gets compressed, then

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message