Re: [Resin-interest] Problem with gzip compression for javascript downloads from Linux server
On Aug 23, 2007, at 8:39 PM, Michael L. Davis wrote: Hi, So I touch'ed prototype-compressed.js (to get rid of the 403) and we get: [0] GET /startpage/scripts/prototype-compressed.js HTTP/1.1 [0] Remote-IP: 75.71.75.22:3697 [0] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 [0] Accept: */* [0] Accept-Language: en-us,en;q=0.5 [0] Accept-Encoding: gzip,deflate [0] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 [0] Keep-Alive: 300 [0] Connection: keep-alive [0] If-Modified-Since: Wed, 15 Aug 2007 21:22:02 GMT [0] If-None-Match: 831XFs4IZoh [0] Cache-Control: max-age=0 [0] HTTP/1.1 200 OK [0] ETag: 8UCDSWLScH5 [0] Last-Modified: Fri, 24 Aug 2007 01:28:45 GMT [0] Accept-Ranges: bytes [0] Cache-Control: max-age=5 [0] Expires: Fri, 24 Aug 2007 01:28:57 GMT [0] Content-Type: application/x-javascript [0] Content-Length: 52498 [0] write-chunk(16384) Thanks. I've filed a bug at http://bugs.caucho.com/view.php? id=1972.That looks like it should be compressable, but it's not getting compressed. -- Scott AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] [0] write-chunk(16384) AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] [0] write-chunk(16384) AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] caching: /startpage/scripts/prototype-compressed.js etag=8UCDSWLScH5 length=52498 [0] keepalive [0] keepalive (select) The 'write-chunk(16284)' looks like it is trying to do something - but FireBug and that website that sends HEAD instead of GET both report 53K. If someone can convince me that FireBug is just plain wrong (tho it correctly reports on Windows XP) ... OK. Maybe FireBug et. al. ARE wrong. I opened a fresh FireFox window over dialup and it took 27 seconds (a page refresh then took 2 seconds) , 1/3 the time that the websiteoptimization.com site said it should and 1/2 the time a back-of-the-envelope calculation indicated. And given that the JS is most of the bytes going over the line, I now think that it IS being compressed but incorrectly reported on. So, uh, I will continue to investigate, but I am afraid I have bothered everybody needlessly. Thanks for your help! Mike. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Problem with gzip compression for javascript downloads from Linux server
Hi, So I touch'ed prototype-compressed.js (to get rid of the 403) and we get: [0] GET /startpage/scripts/prototype-compressed.js HTTP/1.1 [0] Remote-IP: 75.71.75.22:3697 [0] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 [0] Accept: */* [0] Accept-Language: en-us,en;q=0.5 [0] Accept-Encoding: gzip,deflate [0] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 [0] Keep-Alive: 300 [0] Connection: keep-alive [0] If-Modified-Since: Wed, 15 Aug 2007 21:22:02 GMT [0] If-None-Match: 831XFs4IZoh [0] Cache-Control: max-age=0 [0] HTTP/1.1 200 OK [0] ETag: 8UCDSWLScH5 [0] Last-Modified: Fri, 24 Aug 2007 01:28:45 GMT [0] Accept-Ranges: bytes [0] Cache-Control: max-age=5 [0] Expires: Fri, 24 Aug 2007 01:28:57 GMT [0] Content-Type: application/x-javascript [0] Content-Length: 52498 [0] write-chunk(16384) AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] [0] write-chunk(16384) AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] [0] write-chunk(16384) AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] AutoCommitWriteBlock[Store[2],2] create db-block remove AutoCommitWriteBlock[Store[2],2] caching: /startpage/scripts/prototype-compressed.js etag=8UCDSWLScH5 length=52498 [0] keepalive [0] keepalive (select) The 'write-chunk(16284)' looks like it is trying to do something - but FireBug and that website that sends HEAD instead of GET both report 53K. If someone can convince me that FireBug is just plain wrong (tho it correctly reports on Windows XP) ... OK. Maybe FireBug et. al. ARE wrong. I opened a fresh FireFox window over dialup and it took 27 seconds (a page refresh then took 2 seconds) , 1/3 the time that the websiteoptimization.com site said it should and 1/2 the time a back-of-the-envelope calculation indicated. And given that the JS is most of the bytes going over the line, I now think that it IS being compressed but incorrectly reported on. So, uh, I will continue to investigate, but I am afraid I have bothered everybody needlessly. Thanks for your help! Mike. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Problem with gzip compression for javascript downloads from Linux server
Michael L. Davis wrote: The 'write-chunk(16284)' looks like it is trying to do something - but FireBug and that website that sends HEAD instead of GET both report 53K. If someone can convince me that FireBug is just plain wrong (tho it correctly reports on Windows XP) ... I've never seen a case where FireBug reported incorrect headers (and I can't imagine where it would get them) but you can use a packet capture and analysis tool, which also works across all browsers, if you want to be sure. OK. Maybe FireBug et. al. ARE wrong. I opened a fresh FireFox window over dialup and it took 27 seconds (a page refresh then took 2 seconds) , 1/3 the time that the websiteoptimization.com site said it should and 1/2 the time a back-of-the-envelope calculation indicated. And given that the JS is most of the bytes going over the line, I now think that it IS being compressed but incorrectly reported on. Dial-up modems transparently compress the data stream so you can't make those assumptions. HTH, Michaeljohn ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Problem with gzip compression for javascript downloads from Linux server
On Aug 16, 2007, at 2:13 PM, Michael L. Davis wrote: Hi Everybody, Using Resin Pro 3.0.23, enabling gzip compression works on Windows XP, specifically the large (300K+) amount of javascript we use gets compressed to 25% or so. Very nice. But on Linux, only the HTML is compressed. This we verified using: http://www.websiteoptimization.com/services/analyze/index.html and Firefox's FireBug. Can you look at the headers that the client is sending to Resin? (level=finer will show those) It's possible that the gzip filter isn't properly handling the Accept- Encoding from the client. -- Scott The Linux version is: CentOS release 4.5 (Final) What we have in conf (and we've tried a number of variations) is: web-app id=/ document-directory=/var/www/resin/deploy filter filter-name=gzip filter-class=com.caucho.filters.GzipFilter/ filter-mapping filter-name=gzip url-pattern exclude-pattern*.pdf/exclude- pattern include-pattern/*/include-pattern /url-pattern /filter-mapping /web-app Any suggestions? Anybody? Thanks, Mike. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
