@jakarta.apache.org
Subject: Re: HTTP/1.1 GZIP compression and its impact on server
Hi ,
On 8/1/05, George Sexton [EMAIL PROTECTED] wrote:
Our App does GZIP compression. I actually did some real
testing on using it.
Here's what we tell our customers:
Enable GZIP Compression
Subject: Re: HTTP/1.1 GZIP compression and its impact on server
Hi ,
On 8/1/05, George Sexton [EMAIL PROTECTED] wrote:
Our App does GZIP compression. I actually did some real
testing on using it.
Here's what we tell our customers:
Enable GZIP Compression
Enabling
Message-
From: Peddireddy Srikanth [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 02, 2005 9:02 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: HTTP/1.1 GZIP compression and its impact on server
Hi ,
On 8/1/05, George Sexton [EMAIL PROTECTED] wrote:
Our App does GZIP compression
Hi ,
On 8/1/05, George Sexton [EMAIL PROTECTED] wrote:
Our App does GZIP compression. I actually did some real testing on using it.
Here's what we tell our customers:
Enable GZIP Compression
Enabling this option will cause Connect Daily to send web pages to the
browser compressed in the
Our App does GZIP compression. I actually did some real testing on using it.
Here's what we tell our customers:
Enable GZIP Compression
Enabling this option will cause Connect Daily to send web pages to the
browser compressed in the GZIP format. This can result in a compression
factor of six (6)
Ethernet uses packets of 1500 bytes, this includes some headers. So if your
html is smaller than about 1400 bytes your are sending the same number of
packets over your network with or without compression. If the size of the html
is larger you are winning some packets/sec with compression. But
From: Ronald Klop [mailto:[EMAIL PROTECTED]
Ethernet uses packets of 1500 bytes, this includes some
headers. So if your html is smaller than about 1400 bytes
your are sending the same number of packets over your network
with or without compression.
Not entirely true, as for Internet use
On 7/29/05, Ronald Klop [EMAIL PROTECTED] wrote:
Compressing images is useless. We compress css and javascript and don't have
problems
with it, but our customers use quite new browsers, because the application
doesn't work in
pre-mozilla/pre-ie-5.5 at all.
I've had problems with
thanx for ur help
i will go forward in using GZIP for my application.
can you tell me what would be the ideal page (or image or what ever it
may be) size over which we can apply compression, so that we dont
waste resources compressing smaller pages. I think may be compressing
each and every page
On 7/28/05, Peddireddy Srikanth [EMAIL PROTECTED] wrote:
can you tell me what would be the ideal page (or image or what ever it
may be) size over which we can apply compression, so that we dont
waste resources compressing smaller pages. I think may be compressing
each and every page will
It will eat up CPU, but you also save CPU by not having to transmit those
extra bytes.
Its always a good idea to GZIP.
-Tim
Peddireddy Srikanth wrote:
Hi all,
Iam planning to turn on the HTTP/1.1 GZIP compression for my
application by setting the compression attribute of http connector.
Iam
I'm using this in a 4-node cluster serving about 30 req/s. And didn't really
notice any difference in cpu usage. (I think generating my pages use more
cpu-power than compressing them.)
Ronald.
On Tue Jul 26 08:33:07 CEST 2005 Tomcat Users List
tomcat-user@jakarta.apache.org wrote:
Hi all,
If you have enough bandwidth yourself, the big win is in the saved bandwidth on
the client-side and that is what your customers like. The browser wil act
quicker because it has more data to render in a shorter time.
On Tue Jul 26 12:46:07 CEST 2005 Tomcat Users List
13 matches
Mail list logo