Re: HTTP/1.1 GZIP compression and its impact on server
I thought our discussion on GZIP is almost complete untill one of collegue said that , just enabling it by adding required attributes for connector tag in server.xml is not enough, but we need tp do some coding too probably using some filters . Is this true?? But the documentation doesnt speak anything about this. so please clarify on this last doubt thank you Regards Srikanth On 8/4/05, Peddireddy Srikanth [EMAIL PROTECTED] wrote: thanks for the help Ya I agree with you in bandwidth and responsiveness issue. We started using GZIP in test environment and most probably we would go into prodcution with compression turned on. Thanks again for your help Srikanth On 8/3/05, George Sexton [EMAIL PROTECTED] wrote: Yes. In my particular case, the server throughput in requests fell by 2.3%. Of course, the bandwidth utilization fell also from 6Mb/s to 1.0Mb/s. Additionally, you have to ask yourself how much more responsive the application will seem to users. We host our web calendar application, and we run compression on it. Actually, at the co-location site we are moving to, we pay for bandwidth usage. It's probably going to be cheaper to put another machine in than to use 6 times more bandwidth. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original 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. 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) times. Needless to say, this can make your calendar noticeably faster to end users. Our testing indicates serviced per minute was reduced by 2.3% when GZIP compression is enabled. This means once u started using GZIP number of requests that are services by your server in one minute is fallen by 2.3 %. Essentially server's throughput is fallen. Am I right ?? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
This is untrue at least in Tomcat 5. But why don't you try it instead of having discussions about it? Use a network sniffer to check what the server is sending over the wire. Ronald. On Tue Aug 09 10:05:19 CEST 2005 Tomcat Users List tomcat-user@jakarta.apache.org wrote: I thought our discussion on GZIP is almost complete untill one of collegue said that , just enabling it by adding required attributes for connector tag in server.xml is not enough, but we need tp do some coding too probably using some filters . Is this true?? But the documentation doesnt speak anything about this. so please clarify on this last doubt thank you Regards Srikanth On 8/4/05, Peddireddy Srikanth [EMAIL PROTECTED] wrote: thanks for the help Ya I agree with you in bandwidth and responsiveness issue. We started using GZIP in test environment and most probably we would go into prodcution with compression turned on. Thanks again for your help Srikanth On 8/3/05, George Sexton [EMAIL PROTECTED] wrote: Yes. In my particular case, the server throughput in requests fell by 2.3%. Of course, the bandwidth utilization fell also from 6Mb/s to 1.0Mb/s. Additionally, you have to ask yourself how much more responsive the application will seem to users. We host our web calendar application, and we run compression on it. Actually, at the co-location site we are moving to, we pay for bandwidth usage. It's probably going to be cheaper to put another machine in than to use 6 times more bandwidth. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original 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. 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) times. Needless to say, this can make your calendar noticeably faster to end users. Our testing indicates serviced per minute was reduced by 2.3% when GZIP compression is enabled. This means once u started using GZIP number of requests that are services by your server in one minute is fallen by 2.3 %. Essentially server's throughput is fallen. Am I right ?? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
thanks for the help Ya I agree with you in bandwidth and responsiveness issue. We started using GZIP in test environment and most probably we would go into prodcution with compression turned on. Thanks again for your help Srikanth On 8/3/05, George Sexton [EMAIL PROTECTED] wrote: Yes. In my particular case, the server throughput in requests fell by 2.3%. Of course, the bandwidth utilization fell also from 6Mb/s to 1.0Mb/s. Additionally, you have to ask yourself how much more responsive the application will seem to users. We host our web calendar application, and we run compression on it. Actually, at the co-location site we are moving to, we pay for bandwidth usage. It's probably going to be cheaper to put another machine in than to use 6 times more bandwidth. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original 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. 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) times. Needless to say, this can make your calendar noticeably faster to end users. Our testing indicates serviced per minute was reduced by 2.3% when GZIP compression is enabled. This means once u started using GZIP number of requests that are services by your server in one minute is fallen by 2.3 %. Essentially server's throughput is fallen. Am I right ?? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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) times. Needless to say, this can make your calendar noticeably faster to end users. Our testing indicates serviced per minute was reduced by 2.3% when GZIP compression is enabled. This means once u started using GZIP number of requests that are services by your server in one minute is fallen by 2.3 %. Essentially server's throughput is fallen. Am I right ?? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP/1.1 GZIP compression and its impact on server
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) times. Needless to say, this can make your calendar noticeably faster to end users. Our testing indicates serviced per minute was reduced by 2.3% when GZIP compression is enabled. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Peddireddy Srikanth [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 26, 2005 12:33 AM To: Tomcat Users List Subject: HTTP/1.1 GZIP compression and its impact on server 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 sure that this will reduce my bandwidth requirements. But I have a doubt. Is Compressing the responses will eat away many CPU cycles and affect my throughput or performance or scalability. Any one have used this option in production environment and what r the results(performance etc) thanx for any info on this . Regards Srikanth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
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 I can't say this saves you some cpu time for not compressing small pages. If the performance of your application depends on these small things you have a very efficient application. ;-) I think you can better spend some time profiling the rest of the application to win in cpu speed. NB: The ethernet packet size isn't the 'global internet' packet size, but most networks support this size. 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. Ronald. On Fri Jul 29 04:20:35 CEST 2005 Tomcat Users List tomcat-user@jakarta.apache.org wrote: 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 will negate the gains that we achieve by compressing. Also can you tell me whether it is appropriate to apply compression on image files (like .gif, . jpeg etc) as some of image formats are compressed already in themselves. Regards Srikanth On 7/26/05, Ronald Klop [EMAIL PROTECTED] wrote: 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 tomcat-user@jakarta.apache.org wrote: 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 sure that this will reduce my bandwidth requirements. But I have a doubt. Is Compressing the responses will eat away many CPU cycles and affect my throughput or performance or scalability. Any one have used this option in production environment and what r the results(performance etc) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP/1.1 GZIP compression and its impact on server
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 intermediate routers may have their own Maximum Transfer Unit (MTU), and TCP tries to guess the MTU, usually starting at a segment size of 576 bytes of payload and moving up or down on a per-connection basis. Finally, gigabit and above Ethernet allow frame bursts and may allow larger frame sizes. Unless you have only Ethernet between your server and your clients, with no wide-area network segments, it's unwise to assume a packet size. Even if you only have Ethernet, different OSs handle the TCP segment size differently. If the performance of your application depends on these small things you have a very efficient application. ;-) I think you can better spend some time profiling the rest of the application to win in cpu speed. Absolutely! Compressing images is useless. Assuming they're already in a compressed format such as GIF, JPEG, PNG. Uncompressed formats such as BMP would still benefit, but I wouldn't expect most folks to be using them in an Internet app! - Peter PS: Beware, my knowledge of the innards of TCP/IP was current some years ago, and some of the numbers may be off! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
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 compressed css/javascript using Firefox 1.0.6 and seem to encounter occasional problems with IE 6 based on reports from customers. My problems seem to occur on SSL sites, Firefox seems to not load referenced css/javascript files correctly on occasion. For example, if using Squirrelmail, it seems that the occasionally css doesn't get loaded correctly in one of the frames and I've seen similar behavior where a javascript file doesn't get loaded causing javascript errors. Hard to reproduce. I'm guessing it has to do the combination of content compression and SSL and some timing bugs. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
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 will negate the gains that we achieve by compressing. Also can you tell me whether it is appropriate to apply compression on image files (like .gif, . jpeg etc) as some of image formats are compressed already in themselves. Regards Srikanth On 7/26/05, Ronald Klop [EMAIL PROTECTED] wrote: 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 tomcat-user@jakarta.apache.org wrote: 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 sure that this will reduce my bandwidth requirements. But I have a doubt. Is Compressing the responses will eat away many CPU cycles and affect my throughput or performance or scalability. Any one have used this option in production environment and what r the results(performance etc) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
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 negate the gains that we achieve by compressing. Also can you tell me whether it is appropriate to apply compression on image files (like .gif, . jpeg etc) as some of image formats are compressed already in themselves. As long as the page is over a few kBytes, it is generally worth compressing. However, the performance difference for compressing or not compressing small pages is fairly insignificant so it's easier to just compress all html content. I have seen problems with both MSIE and Firefox when serving them compressed CSS and Javascript files, so I can only recommend that you serve compressed text/html, text/plain and text/xml. Don't bother compressing image files, they should already be compressed. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
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 sure that this will reduce my bandwidth requirements. But I have a doubt. Is Compressing the responses will eat away many CPU cycles and affect my throughput or performance or scalability. Any one have used this option in production environment and what r the results(performance etc) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
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, Iam planning to turn on the HTTP/1.1 GZIP compression for my application by setting the compression attribute of http connector. Iam sure that this will reduce my bandwidth requirements. But I have a doubt. Is Compressing the responses will eat away many CPU cycles and affect my throughput or performance or scalability. Any one have used this option in production environment and what r the results(performance etc) thanx for any info on this . Regards Srikanth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP/1.1 GZIP compression and its impact on server
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 tomcat-user@jakarta.apache.org wrote: 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 sure that this will reduce my bandwidth requirements. But I have a doubt. Is Compressing the responses will eat away many CPU cycles and affect my throughput or performance or scalability. Any one have used this option in production environment and what r the results(performance etc) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
