Compression and SSL

[Jeffrey Janner]

OK, another newbie-ish question here.

 

I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32 or
Windows 2008 x64 to serve applications from the US to Asia-based
clients.

We encrypt everything using SSL, from Login page onward, with
<transport-guarantee> of CONFIDENTIAL.

All URLs are configured as relative, i.e., "/images/picture.png",
"/APP1?param1=value....", etc.

We use Tomcat as the web server with no intervening proxies,
load-balancers, accelerators, etc.

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

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

Does it compress before or after applying the encryption?

 

And,  in case it's relevant, here is the relevant excerpt from the
web.xml file we use:

 

  <security-constraint>

    <web-resource-collection>

      <web-resource-name>Everything</web-resource-name>

      <url-pattern>*.jsp</url-pattern>

      <url-pattern>*.html</url-pattern>

      <url-pattern>*.js</url-pattern>

      <url-pattern>/APP1</url-pattern>

      <url-pattern>/APP2</url-pattern>

    </web-resource-collection>

    <user-data-constraint>

      <transport-guarantee>CONFIDENTIAL</transport-guarantee>

    </user-data-constraint>

  </security-constraint>

 

Any assistance would be much appreciated.

 

Jeff


*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.

[Pid Ster]

On 02/11/2009 16:48, Jeffrey Janner wrote:

> OK, another newbie-ish question here.
>
>
>
> I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32 or
> Windows 2008 x64 to serve applications from the US to Asia-based
> clients.
>
> We encrypt everything using SSL, from Login page onward, with
> <transport-guarantee>  of CONFIDENTIAL.
>
> All URLs are configured as relative, i.e., "/images/picture.png",
> "/APP1?param1=value....", etc.
>
> We use Tomcat as the web server with no intervening proxies,
> load-balancers, accelerators, etc.
>
> Response time is noticeably slow (based on complaint level) and I am
> looking for ways to improve it.

Bigger server?

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

What makes you think that compressing things is going to improve
matters?  Doing the compression is an overhead itself.

What's slow about your app and how do you know it?

> Does it compress before or after applying the encryption?
>
> And,  in case it's relevant, here is the relevant excerpt from the
> web.xml file we use:
>
>
>
>    <security-constraint>
>
>      <web-resource-collection>
>
>        <web-resource-name>Everything</web-resource-name>
>
>        <url-pattern>*.jsp</url-pattern>
>
>        <url-pattern>*.html</url-pattern>
>
>        <url-pattern>*.js</url-pattern>

Brevity:

   <url-pattern>/*</url-pattern>

>        <url-pattern>/APP1</url-pattern>
>        <url-pattern>/APP2</url-pattern>

If those actually represent real webapps, with their own
WEB-INF/web.xml, the lines above don't do anything.

p

>      </web-resource-collection>
>
>      <user-data-constraint>
>
>        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>
>      </user-data-constraint>
>
>    </security-constraint>
>
>
>
> Any assistance would be much appreciated.
>
>
>
> Jeff
>
>
> *******************************  NOTICE  *********************************
> This message is intended for the use of the individual or entity to which
> it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law.  If the
> reader of this message is not the intended recipient or the employee or
> agent responsible for delivering this message to the intended recipient,
> you are hereby notified that any dissemination, distribution, or copying
> of this communication is strictly prohibited.  If you have received this
> communication in error, please notify us immediately by reply or by
> telephone (call us collect at 512-343-9100) and immediately delete this
> message and all its attachments.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[awarnier]

Jeffrey Janner wrote:
> OK, another newbie-ish question here.
>
Then a dummy-ish answer may be sufficient :

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

It will compress all data it would compress it it wasn't HTTPS.

>
> Does it compress before or after applying the encryption?
>
Before.
HTTPS is at a lower level, at the connection level.
I'm not even sure that Tomcat is really involved.  As far as responses
are concerned, Tomcat probably just hands them over to the socket (in
clear, normal), and it is the socket which does the SSL encryption.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[George Sexton]

> -----Original Message-----
> From: Pid [mailto:pid@...]
> Sent: Monday, November 02, 2009 11:12 AM
> To: Tomcat Users List
> Subject: Re: Compression and SSL
>
> On 02/11/2009 16:48, Jeffrey Janner wrote:
> > OK, another newbie-ish question here.
> >
> >
> >
> > I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32
> or
> > Windows 2008 x64 to serve applications from the US to Asia-based
> > clients.
> >
> > We encrypt everything using SSL, from Login page onward, with
> > <transport-guarantee>  of CONFIDENTIAL.
> >
> > All URLs are configured as relative, i.e., "/images/picture.png",
> > "/APP1?param1=value....", etc.
> >
> > We use Tomcat as the web server with no intervening proxies,
> > load-balancers, accelerators, etc.
> >
> > Response time is noticeably slow (based on complaint level) and I am
> > looking for ways to improve it.
>
> Bigger server?
>
> > Will setting the HTTPS connector "compression=on" actually compress
> the
> > data for HTTPS?
>
> What makes you think that compressing things is going to improve
> matters?  Doing the compression is an overhead itself.
>

In general, Compressing HTML can help a great deal for any case besides a
local network.

A typical HTML page will compress by a factor of 6 or so. Compressing a 42 K
page can result in a 7K page. This reduces the typical packet count from 28
or so to around 5.

Even with the overhead of compressing the HTML on the server, and
decompressing it, this can yield a great performance improvement for any
user. If there are fewer packets, there are fewer lost packets.
Additionally, you're reducing the overhead of sending the packets through
the OS.

If you're serving a great deal of data, through a pipe of a fixed size, this
effectively makes your pipe 6 times bigger (assuming it's mostly HTML you
move). So, your pipe isn't as full, and you're not paying for as much
bandwidth.


So, compression of HTML is a really valid technique that will be helpful for
any case beyond the local network. The one caveat is the compressability of
the data. For example, you're not going to get much improvement attempting
to compress JPG images.


George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Peter Crowther]

2009/11/2 George Sexton <georges@...>

> In general, Compressing HTML can help a great deal for any case besides a
> local network.
>

... or a CPU-limited server.

To the OP: What's the bottleneck in your environment?  CPU?  Disk I/O?
Network bandwidth?  Measure the problem, *then* look for solutions to the
problem that actually exists.  If you've measured and you have CPU to spare
but are bandwidth-limited, then compression will help a great deal!

- Peter

[George Sexton]

> -----Original Message-----
> From: peter.crowther3@...
> [mailto:peter.crowther3@...] On Behalf Of Peter Crowther
> Sent: Monday, November 02, 2009 12:35 PM
> To: Tomcat Users List
> Subject: Re: Compression and SSL
>
> 2009/11/2 George Sexton <georges@...>
>
> > In general, Compressing HTML can help a great deal for any case
> besides a
> > local network.
> >

You didn't read the original post very closely.

>> to serve applications from the US to Asia-based clients.

It's bandwidth and latency.

>
> ... or a CPU-limited server.
>
> To the OP: What's the bottleneck in your environment?  CPU?  Disk I/O?
> Network bandwidth?  Measure the problem, *then* look for solutions to
> the
> problem that actually exists.  If you've measured and you have CPU to
> spare
> but are bandwidth-limited, then compression will help a great deal!
>
> - Peter

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeffrey,

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

[snip]

> 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
encrypted.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrvPK4ACgkQ9CaO5/Lv0PA5HgCdEwrU7Ie8YrJDQLROxH5YPdHN
ALUAoLKVSGnrCfS0TgBhjFr5PJdUQ00I
=MG89
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeffrey Janner]

Pid -
Windows 64-bit Dual Quad-Core w/32G RAM.  Do I really need bigger?
App's not really slow-- works great here.  But with a 300ms latency
(one-way) to The Orient, you can see why I might want to send as few
bits as possible.
Jeff

-----Original Message-----
From: Pid [mailto:pid@...]
Sent: Monday, November 02, 2009 12:12 PM
To: Tomcat Users List
Subject: Re: Compression and SSL

On 02/11/2009 16:48, Jeffrey Janner wrote:
> OK, another newbie-ish question here.
>
>
>
> I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32
or

> Windows 2008 x64 to serve applications from the US to Asia-based
> clients.
>
> We encrypt everything using SSL, from Login page onward, with
> <transport-guarantee>  of CONFIDENTIAL.
>
> All URLs are configured as relative, i.e., "/images/picture.png",
> "/APP1?param1=value....", etc.
>
> We use Tomcat as the web server with no intervening proxies,
> load-balancers, accelerators, etc.
>
> Response time is noticeably slow (based on complaint level) and I am
> looking for ways to improve it.

Bigger server?

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

What makes you think that compressing things is going to improve
matters?  Doing the compression is an overhead itself.

What's slow about your app and how do you know it?

> Does it compress before or after applying the encryption?
>
> And,  in case it's relevant, here is the relevant excerpt from the
> web.xml file we use:
>
>
>
>    <security-constraint>
>
>      <web-resource-collection>
>
>        <web-resource-name>Everything</web-resource-name>
>
>        <url-pattern>*.jsp</url-pattern>
>
>        <url-pattern>*.html</url-pattern>
>
>        <url-pattern>*.js</url-pattern>

Brevity:

   <url-pattern>/*</url-pattern>

>        <url-pattern>/APP1</url-pattern>
>        <url-pattern>/APP2</url-pattern>

If those actually represent real webapps, with their own
WEB-INF/web.xml, the lines above don't do anything.

p

>      </web-resource-collection>
>
>      <user-data-constraint>
>
>        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>
>      </user-data-constraint>
>
>    </security-constraint>
>
>
>
> Any assistance would be much appreciated.
>
>
>
> Jeff
>
>
> *******************************  NOTICE

*********************************
> This message is intended for the use of the individual or entity to
which
> it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law.  If the
> reader of this message is not the intended recipient or the employee
or
> agent responsible for delivering this message to the intended
recipient,
> you are hereby notified that any dissemination, distribution, or
copying
> of this communication is strictly prohibited.  If you have received
this
> communication in error, please notify us immediately by reply or by
> telephone (call us collect at 512-343-9100) and immediately delete
this
> message and all its attachments.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeffrey Janner]

André -
Thanks for the nice answer.
Precisely what I was looking for to make a decision.
I'll try turning it on for one customer tonight and see if we really improve things.
Jeff

-----Original Message-----
From: André Warnier [mailto:aw@...]
Sent: Monday, November 02, 2009 12:59 PM
To: Tomcat Users List
Subject: Re: Compression and SSL

Jeffrey Janner wrote:
> OK, another newbie-ish question here.
>
Then a dummy-ish answer may be sufficient :

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

It will compress all data it would compress it it wasn't HTTPS.

>
> Does it compress before or after applying the encryption?
>
Before.
HTTPS is at a lower level, at the connection level.
I'm not even sure that Tomcat is really involved.  As far as responses
are concerned, Tomcat probably just hands them over to the socket (in
clear, normal), and it is the socket which does the SSL encryption.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeffrey Janner]

Peter -
It's primarily the network bandwidth.
The best-case latency to Asia from the US is about 150ms (assuming
speed-of-light, no hardware delays).
What we see on bi-directional traceroutes is an "across-the-ocean" delay
of 200ms to 300ms on a good day.
That translates to adding roughly 1 second to response time.
Depending on the page, we probably run from 8k to 1-2 Mb of text.  And
that doesn't include uploads/downloads of user's files.
Jeff

-----Original Message-----
From: peter.crowther3@...
[mailto:peter.crowther3@...] On Behalf Of Peter Crowther
Sent: Monday, November 02, 2009 1:35 PM
To: Tomcat Users List
Subject: Re: Compression and SSL

2009/11/2 George Sexton <georges@...>

> In general, Compressing HTML can help a great deal for any case
besides a
> local network.
>

... or a CPU-limited server.

To the OP: What's the bottleneck in your environment?  CPU?  Disk I/O?
Network bandwidth?  Measure the problem, *then* look for solutions to
the
problem that actually exists.  If you've measured and you have CPU to
spare
but are bandwidth-limited, then compression will help a great deal!

- Peter

*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeffrey Janner]

From: Christopher Schultz [mailto:chris@...]


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

>Any reason to suspect it wouldn't?

Some result from a Google search I did trying to find a solution to this issue led me to infer that it didn't.  I figured it was wrong but thought I'd ask the gurus.

>> 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
>encrypted.

That's what I figured it should do.

*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.

[Jeffrey Janner]

Thanks for all the suggestions so far guys.
Are there any other tips I could provide to the developers that they can
do to improve throughput?
Should they hard-code the http:// for all the static elements to avoid
passing them over SSL, or do my security constraints take care of that?
(I doub it.)
The original URL gets redirected to https immediately, so I'm thinking
everything from there on out is SSL.  Correct?
Can I get more granular?  I'd be happy for a pointer to a good reference
on the subject.
Jeff

-----Original Message-----
From: George Sexton [mailto:georges@...]
Sent: Monday, November 02, 2009 1:56 PM
To: 'Tomcat Users List'
Subject: RE: Compression and SSL

> -----Original Message-----
> From: peter.crowther3@...
> [mailto:peter.crowther3@...] On Behalf Of Peter Crowther
> Sent: Monday, November 02, 2009 12:35 PM
> To: Tomcat Users List
> Subject: Re: Compression and SSL
>
> 2009/11/2 George Sexton <georges@...>
>
> > In general, Compressing HTML can help a great deal for any case
> besides a
> > local network.
> >

You didn't read the original post very closely.

>> to serve applications from the US to Asia-based clients.

It's bandwidth and latency.

>
> ... or a CPU-limited server.
>
> To the OP: What's the bottleneck in your environment?  CPU?  Disk I/O?
> Network bandwidth?  Measure the problem, *then* look for solutions to
> the
> problem that actually exists.  If you've measured and you have CPU to
> spare
> but are bandwidth-limited, then compression will help a great deal!
>
> - Peter

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[awarnier]

Jeffrey Janner wrote:
> Thanks for all the suggestions so far guys.
> Are there any other tips I could provide to the developers that they can
> do to improve throughput?
> Should they hard-code the http:// for all the static elements to avoid
> passing them over SSL,

If these items are not sensitive, that /could/ be a good idea, except
that IE is probably going to bother your users no-end, popping up
friendly warnings that this site is switching between secure and
non-secure pages, so they'll probably wonder which brain-dead designer
came up with this scheme.

or do my security constraints take care of that?
> (I doub it.)

You're right to doubt, they will do nothing of the kind.

> The original URL gets redirected to https immediately, so I'm thinking
> everything from there on out is SSL.  Correct?

Yes, inasfar as links in html pages are concerned.  You have to look at
it from the browser's point of view.  When it sees an "incomplete" link,
it completes it using the protocol and hostname from which the current
page was obtained, and then it requests that object.

> Can I get more granular?  I'd be happy for a pointer to a good reference
> on the subject.

There are probably tons on Google, if you look for "website
optimi[z,s]ation" or the like.

Personally, I have found that a very large proportion of websites on the
WWW are slow because their designers just /don't think/.  If loading
each page requires 10 or more requests to the server and you fail to
organise stuff so that it can be cached by the browser, then you should
not be surprised that your site feels slow.  But it never ceases to
amaze me how many sites ignore the simple common-sense principles.
I would bet that carefully examining what you are actually sending in
your pages and cleaning it up would yeld more benefits, faster, than
playing around with protocols, compression and the like.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Pid Ster]

On 02/11/2009 23:34, Jeffrey Janner wrote:
> Pid -
> Windows 64-bit Dual Quad-Core w/32G RAM.  Do I really need bigger?
> App's not really slow-- works great here.  But with a 300ms latency
> (one-way) to The Orient, you can see why I might want to send as few
> bits as possible.
> Jeff

Indeed. Was just asking.

What portion of the resources sent are static, and have you considered
hosting those physically closer to your clients?

If you've got a typical web page type setup, then most of the response
time is made up of the (bi)sequential download of the extra resources
served after the browser has processed the HTML.

A quick look at the network profiler in Firebug ought to make it clear
what's happening.

If you can expect an average of 250ms for *every* resource, then even
the cost of a little big of logic, to set a different server URL for
those static resources, will probably pay off big time.

Even a cheap low power server might offer a better service if the
resources are small enough, and it's in the locality.


p

> -----Original Message-----
> From: Pid [mailto:pid@...]
> Sent: Monday, November 02, 2009 12:12 PM
> To: Tomcat Users List
> Subject: Re: Compression and SSL
>
> On 02/11/2009 16:48, Jeffrey Janner wrote:
>> OK, another newbie-ish question here.
>>
>>
>>
>> I am using Tomcat 5.5.x with APR/native libraries on Windows 2003 x32
> or
>> Windows 2008 x64 to serve applications from the US to Asia-based
>> clients.
>>
>> We encrypt everything using SSL, from Login page onward, with
>> <transport-guarantee>   of CONFIDENTIAL.
>>
>> All URLs are configured as relative, i.e., "/images/picture.png",
>> "/APP1?param1=value....", etc.
>>
>> We use Tomcat as the web server with no intervening proxies,
>> load-balancers, accelerators, etc.
>>
>> Response time is noticeably slow (based on complaint level) and I am
>> looking for ways to improve it.
>
> Bigger server?
>
>> Will setting the HTTPS connector "compression=on" actually compress
> the
>> data for HTTPS?
>
> What makes you think that compressing things is going to improve
> matters?  Doing the compression is an overhead itself.
>
> What's slow about your app and how do you know it?
>
>
>> Does it compress before or after applying the encryption?
>>
>> And,  in case it's relevant, here is the relevant excerpt from the
>> web.xml file we use:
>>
>>
>>
>>     <security-constraint>
>>
>>       <web-resource-collection>
>>
>>         <web-resource-name>Everything</web-resource-name>
>>
>>         <url-pattern>*.jsp</url-pattern>
>>
>>         <url-pattern>*.html</url-pattern>
>>
>>         <url-pattern>*.js</url-pattern>
>
> Brevity:
>
>     <url-pattern>/*</url-pattern>
>
>>         <url-pattern>/APP1</url-pattern>
>>         <url-pattern>/APP2</url-pattern>
>
> If those actually represent real webapps, with their own
> WEB-INF/web.xml, the lines above don't do anything.
>
> p
>
>
>>       </web-resource-collection>
>>
>>       <user-data-constraint>
>>
>>         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>
>>       </user-data-constraint>
>>
>>     </security-constraint>
>>
>>
>>
>> Any assistance would be much appreciated.
>>
>>
>>
>> Jeff
>>
>>
>> *******************************  NOTICE
> *********************************
>> This message is intended for the use of the individual or entity to
> which
>> it is addressed and may contain information that is privileged,
>> confidential, and exempt from disclosure under applicable law.  If the
>> reader of this message is not the intended recipient or the employee
> or
>> agent responsible for delivering this message to the intended
> recipient,
>> you are hereby notified that any dissemination, distribution, or
> copying
>> of this communication is strictly prohibited.  If you have received
> this
>> communication in error, please notify us immediately by reply or by
>> telephone (call us collect at 512-343-9100) and immediately delete
> this
>> message and all its attachments.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> *******************************  NOTICE  *********************************
> This message is intended for the use of the individual or entity to which
> it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law.  If the
> reader of this message is not the intended recipient or the employee or
> agent responsible for delivering this message to the intended recipient,
> you are hereby notified that any dissemination, distribution, or copying
> of this communication is strictly prohibited.  If you have received this
> communication in error, please notify us immediately by reply or by
> telephone (call us collect at 512-343-9100) and immediately delete this
> message and all its attachments.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Peter Crowther]

2009/11/2 George Sexton <georges@...>

> You didn't read the original post very closely.
>
> >> to serve applications from the US to Asia-based clients.
>
> It's bandwidth and latency.
>

Actually, yes, I did.  And I saw that, and I suspected latency would be the
answer.  Suspicion is not confirmation however :-).  One thing I've learned
over the last 35 years is to confirm the problem rather than guess at a
solution based on incomplete information.

Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I
agree that bandwidth/latency is the one to solve, as the rest of the
thread's been working on while I've been asleep!

- Peter

[awarnier]

Peter Crowther wrote:
...
> Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I
> agree that bandwidth/latency is the one to solve, as the rest of the
> thread's been working on while I've been asleep!
>
Elaborating a bit on what I mentioned before, and sorry Jeffrey if this
sounds elementary.  But my experience is that this kind of thing is
often overlooked, and people spend time looking at all kinds of esoteric
solutions when the real problem stares them in the face.

It does not take much to check this, and you need do nothing at the
server side.
Get Firefox, and the HttpFox add-on (or any similar combination that
allows you to see what is really going back and forth between browser
and server).

- open the browser, and start HttpFox in it's own window
- clear the HttpFox trace, and start capturing
- in the borwser, call up the first page of your site
- look at the HttpFox trace, to see how many requests/responses this
really generated, and for what.  Pay particular attention to all the
"accessory" things, like images, stylesheets, images called up by
stylesheets, javascript libraries, etc..
You also see the size of each of these things.

- also pay attention to any 4xx status responses (like 404 not found).
It is often the case that, as an application is developed, people change
the names of images, stylesheets etc.. without adapting the links in the
pages which load these things.  Each 404 means that one request went to
the server, the server did not find it, and sent back a 404 response.
Over a long/slow link, these things count.
(Another good source for this is the server access logs)

That was all for your first page, but I'd bet it may already be an
eye-opener as to what is really going on.

- now call the second page, and do the same examination.
If the design and the caching are correct, then you should see quite a
few of 30x responses ("not modified").  That means that the browser sent
a request to the server for some object, conditional upon the fact that
that object had been modified since the browser got it last.  And the
server may just answer "no, it was not modified, use your cached
version".  That saves bandwidth when it works as it should, because
instead of resending the same object to the browser (an image, a
stylesheet, a javascript library, a java applet), the server just sends
one status line.

If you do not see a lot of 30x responses, but a lot of new requests for
images, stylesheets, background images, etc.. with 200 OK responses,
then maybe ask yourself why this second page needs so many things
different from the first page.  Maybe the server has 5 identical (in
content) stylesheets stored, but under different names.

- it is also often the case that people endlessly duplicate the same
style and graphic elements in many directories and sub-directories,
because it is easier to have links like "images/image1.jpg" in all your
pages (and it is also easier for the graphic designers).  If these
images (or other things) have different URL paths on the server, then
for the browser they all look different, and have to be gotten and
cached separately.  If a given image is only in one (URL) place on the
server, then it is retrieved and cached only once).
(If such is the case and you do not want to revise all your pages, then
there are things that can be done at the server side to mitigate the
effects - like aliases, and URL rewrite rules).


And so on..

No kidding, I have seen cases where the graphic designer of the site
thought it nice to have a different background picture for each page, à
250 KB or more per picture.
That may look very nice, and be justified for some kinds of websites
where graphics are a main concern, but for most business appplications
it is less important than latency. YMMV.

Now when you do that, and tell these designers and programmers to clean
up their act, you are not going to be loved.  Nobody likes to clean up.
But you may be able to save 50% of your bandwidth and reclaim a
significant percentage of duplicate files on your servers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Pid Ster]

On 03/11/2009 10:40, André Warnier wrote:

> Peter Crowther wrote:
> ...
>> Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I
>> agree that bandwidth/latency is the one to solve, as the rest of the
>> thread's been working on while I've been asleep!
>>
> Elaborating a bit on what I mentioned before, and sorry Jeffrey if this
> sounds elementary. But my experience is that this kind of thing is often
> overlooked, and people spend time looking at all kinds of esoteric
> solutions when the real problem stares them in the face.
>
> It does not take much to check this, and you need do nothing at the
> server side.
> Get Firefox, and the HttpFox add-on (or any similar combination that
> allows you to see what is really going back and forth between browser
> and server).
>
> - open the browser, and start HttpFox in it's own window
> - clear the HttpFox trace, and start capturing
> - in the borwser, call up the first page of your site
> - look at the HttpFox trace, to see how many requests/responses this
> really generated, and for what. Pay particular attention to all the
> "accessory" things, like images, stylesheets, images called up by
> stylesheets, javascript libraries, etc..
> You also see the size of each of these things.
>
> - also pay attention to any 4xx status responses (like 404 not found).
> It is often the case that, as an application is developed, people change
> the names of images, stylesheets etc.. without adapting the links in the
> pages which load these things. Each 404 means that one request went to
> the server, the server did not find it, and sent back a 404 response.
> Over a long/slow link, these things count.
> (Another good source for this is the server access logs)
>
> That was all for your first page, but I'd bet it may already be an
> eye-opener as to what is really going on.
>
> - now call the second page, and do the same examination.
> If the design and the caching are correct, then you should see quite a
> few of 30x responses ("not modified"). That means that the browser sent
> a request to the server for some object, conditional upon the fact that
> that object had been modified since the browser got it last. And the
> server may just answer "no, it was not modified, use your cached
> version". That saves bandwidth when it works as it should, because
> instead of resending the same object to the browser (an image, a
> stylesheet, a javascript library, a java applet), the server just sends
> one status line.
>
> If you do not see a lot of 30x responses, but a lot of new requests for
> images, stylesheets, background images, etc.. with 200 OK responses,
> then maybe ask yourself why this second page needs so many things
> different from the first page. Maybe the server has 5 identical (in
> content) stylesheets stored, but under different names.
>
> - it is also often the case that people endlessly duplicate the same
> style and graphic elements in many directories and sub-directories,
> because it is easier to have links like "images/image1.jpg" in all your
> pages (and it is also easier for the graphic designers). If these images
> (or other things) have different URL paths on the server, then for the
> browser they all look different, and have to be gotten and cached
> separately. If a given image is only in one (URL) place on the server,
> then it is retrieved and cached only once).
> (If such is the case and you do not want to revise all your pages, then
> there are things that can be done at the server side to mitigate the
> effects - like aliases, and URL rewrite rules).

Seconded.

We minimised the requirements for nth requests, use CSS, cache static
resources as much as possible and substantially improved response times
for remote clients.

Course, there's always more you can do...


p

> And so on..
>
> No kidding, I have seen cases where the graphic designer of the site
> thought it nice to have a different background picture for each page, à
> 250 KB or more per picture.
> That may look very nice, and be justified for some kinds of websites
> where graphics are a main concern, but for most business appplications
> it is less important than latency. YMMV.
>
> Now when you do that, and tell these designers and programmers to clean
> up their act, you are not going to be loved. Nobody likes to clean up.
> But you may be able to save 50% of your bandwidth and reclaim a
> significant percentage of duplicate files on your servers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeffrey Janner]

Well, we already have filters in place to make sure our images, javascript, and other statics go out as cacheable.  In fact, the only thing that should not be cached at this point are the results of the jsp pages themselves.
Did see something recently about combining images into a single file, and then having something on the client end pick out what it needed per page.  Didn't read it all, since it sounds like it requires a bit of coding to support it.  Might be something to tell the dev team about.  I'm just looking at it from changes that an admin can implement.

-----Original Message-----
From: André Warnier [mailto:aw@...]
Sent: Tuesday, November 03, 2009 2:07 AM
To: Tomcat Users List
Subject: Re: Compression and SSL

> Can I get more granular?  I'd be happy for a pointer to a good reference
> on the subject.

There are probably tons on Google, if you look for "website
optimi[z,s]ation" or the like.

Personally, I have found that a very large proportion of websites on the
WWW are slow because their designers just /don't think/.  If loading
each page requires 10 or more requests to the server and you fail to
organise stuff so that it can be cached by the browser, then you should
not be surprised that your site feels slow.  But it never ceases to
amaze me how many sites ignore the simple common-sense principles.
I would bet that carefully examining what you are actually sending in
your pages and cleaning it up would yeld more benefits, faster, than
playing around with protocols, compression and the like.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeffrey Janner]

André -
Yep, it does sound quite elementary, but pointing out a good tool is appreciated.
Since I am also the deployment god (we both host and distribute the app), I usually keep a tight a lid on these things.  Nothing like having to make a bunch of changes to the installer to make my day.  I do my best to make sure there's not a lot of duplication.  So far, my developers do a good job of it as well.
And before I get flack about sticking it in a WAR file, some bonehead decisions by the original developers make this not a very practical option for installing at a customer site, i.e. we have to customize some files that would be in the WAR.
Jeff

-----Original Message-----
From: André Warnier [mailto:aw@...]
Sent: Tuesday, November 03, 2009 4:41 AM
To: Tomcat Users List
Subject: Re: Compression and SSL

Peter Crowther wrote:
...
> Jeffrey's since confirmed it's not a CPU issue - thanks Jeffrey! - so I
> agree that bandwidth/latency is the one to solve, as the rest of the
> thread's been working on while I've been asleep!
>
Elaborating a bit on what I mentioned before, and sorry Jeffrey if this
sounds elementary.  But my experience is that this kind of thing is
often overlooked, and people spend time looking at all kinds of esoteric
solutions when the real problem stares them in the face.


*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Pid Ster]

On 03/11/2009 14:33, Jeffrey Janner wrote:
> Well, we already have filters in place to make sure our images, javascript, and other statics go out as cacheable.  In fact, the only thing that should not be cached at this point are the results of the jsp pages themselves.
> Did see something recently about combining images into a single file, and then having something on the client end pick out what it needed per page.  Didn't read it all, since it sounds like it requires a bit of coding to support it.  Might be something to tell the dev team about.  I'm just looking at it from changes that an admin can implement.

This sounds like the "Sprite" CSS technique.
Doesn't require active code on the client, just a bit of cunning CSSery.

p

> -----Original Message-----
> From: André Warnier [mailto:aw@...]
> Sent: Tuesday, November 03, 2009 2:07 AM
> To: Tomcat Users List
> Subject: Re: Compression and SSL
>
>> Can I get more granular?  I'd be happy for a pointer to a good reference
>> on the subject.
>
> There are probably tons on Google, if you look for "website
> optimi[z,s]ation" or the like.
>
> Personally, I have found that a very large proportion of websites on the
> WWW are slow because their designers just /don't think/.  If loading
> each page requires 10 or more requests to the server and you fail to
> organise stuff so that it can be cached by the browser, then you should
> not be surprised that your site feels slow.  But it never ceases to
> amaze me how many sites ignore the simple common-sense principles.
> I would bet that carefully examining what you are actually sending in
> your pages and cleaning it up would yeld more benefits, faster, than
> playing around with protocols, compression and the like.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> *******************************  NOTICE  *********************************
> This message is intended for the use of the individual or entity to which
> it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law.  If the
> reader of this message is not the intended recipient or the employee or
> agent responsible for delivering this message to the intended recipient,
> you are hereby notified that any dissemination, distribution, or copying
> of this communication is strictly prohibited.  If you have received this
> communication in error, please notify us immediately by reply or by
> telephone (call us collect at 512-343-9100) and immediately delete this
> message and all its attachments.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...