Apache::GzipChain and scalability
I tried out Apache::GzipChain for dynamic mod_perl pages (using Apache::Registry), and it was great for reducing the download time (especially over modem). I am seriously thinking about using it for our production environment. However, some people are concerned about it using up too much resource. Has anyone looked into scalability issues? Would I see significant reduced throughput using GzipChain? Also why don't most sites gzip their pages (do redirect based on browser support)? ___ Why pay when you don't have to? Get AltaVista Free Internet Access now! http://jump.altavista.com/freeaccess4.go ___
Repost: Apache::GzipChain and scalability
I tried out Apache::GzipChain for dynamic mod_perl pages (using Apache::Registry), and it was great for reducing the download ime (especially over modem). I am seriously thinking about using it for our production environment. However, some people are concerned about it using up too much resource. Has anyone looked into scalability issues? Would I see significant reduced throughput using GzipChain? Also why don't most sites gzip their pages (do redirect based on browser support)? Thanks.
Re: Apache::GzipChain and scalability
Bruce Lo wrote: I tried out Apache::GzipChain for dynamic mod_perl pages (using Apache::Registry), and it was great for reducing the download time (especially over modem). I am seriously thinking about using it for our production environment. However, some people are concerned about it using up too much resource. Has anyone looked into scalability issues? Would I see significant reduced throughput using GzipChain? We've been gzipping for a while at eMerchandise.com (though not using gzip chain). We addressed this issue by making the gzip pass decide whether to just pass it through or to do the compression based on current CPU load on the server. So when you've got extra cycles you shrink the file to improve bandwidth utilization, if you're running near peak processor utilization you send the bytes raw. We've had no scaling problems. What kind of system load do your production server(s) see now? What is it during peak traffic periods? Also why don't most sites gzip their pages (do redirect based on browser support)? Because they're lazy or stupid? :) -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | "Forrester Research projects that by 2003, Internet start-ups will have focused so relentlessly on infrastructure that there will be no remaining actual content on the Web. " -- Salon.com 14-Apr-2000
Re: Apache::GzipChain and scalability
Devin Ben-Hur wrote: Bruce Lo wrote: I tried out Apache::GzipChain for dynamic mod_perl pages (using Apache::Registry), and it was great for reducing the download time (especially over modem). I am seriously thinking about using it for our production environment. However, some people are concerned about it using up too much resource. Has anyone looked into scalability issues? Would I see significant reduced throughput using GzipChain? We've been gzipping for a while at eMerchandise.com (though not using gzip chain). We addressed this issue by making the gzip pass decide whether to just pass it through or to do the compression based on current CPU load on the server. So when you've got extra cycles you shrink the file to improve bandwidth utilization, if you're running near peak processor utilization you send the bytes raw. Devin, I have read debates in the past about which browsers will reliably accept gzip content. Do you have a list of such browsers? IIRC, it was IE that was the most troublesome w/ proper display. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Apache::GzipChain and scalability
"Drew" == Drew Taylor [EMAIL PROTECTED] writes: Drew I have read debates in the past about which browsers will reliably Drew accept gzip content. Do you have a list of such browsers? IIRC, it was Drew IE that was the most troublesome w/ proper display. Why base it on browser? Won't checking the request "accept:" for /gzip/ be enough? Then the browser can tell you whether it works or not, and you can just have an exceptions list for those that lie. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Apache::GzipChain and scalability
"Randal L. Schwartz" wrote: "Drew" == Drew Taylor [EMAIL PROTECTED] writes: Drew I have read debates in the past about which browsers will reliably Drew accept gzip content. Do you have a list of such browsers? IIRC, it was Drew IE that was the most troublesome w/ proper display. Why base it on browser? Won't checking the request "accept:" for /gzip/ be enough? Then the browser can tell you whether it works or not, and you can just have an exceptions list for those that lie. Well, in the discussion I was following, it seemed that the browsers didn't always do what they said. IE seemed to be the usual culprit. ;-) I probably won't be using compression any time soon as most of my bandwidth comes from images. But it's good to know that it does work pretty reliably. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
