turn on http compression for front end

[samuel-archive]

Request time is now logged in seconds per request for the front end web server.

Just watching:
$ tail -f -s 0.1 /var/log/lighttpd/current-access.log | grep -v ' [0-9]$'

I noticed a lot of the longer than 9 second requests were for js and css.

Firebug indicates that we aren't doing HTTP compression,

vendor.js:211k
all.css: 100k
all.js: 129k
----------------------
total: 440k

after gzip:

vendor.js: 62k
all.css: 19k
all.js:31k
----------------------
total: 112k

This is very much worth doing.

[George (george-archive)]

Awesome, Sam - thanks!

[Anand Chitipothu (anandology)]

I've this running on my laptop. Will push it to production after more testing.

[Anand Chitipothu (anandology)]

Done.

[samuel-archive (samuel-archive)]

Nice!

while looking at the speedup, i noticed that
vendor.js is lacking a cache-control header,
thus requiring a 304 cycle on each page load ...

-sam

> Done.
>
> ** Changed in: openlibrary
> Status: In Progress => Fix Released
>
> --
> turn on http compression for front end
> https://bugs.launchpad.net/bugs/579606
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Open Library: Fix Released
>
> Bug description:
> Request time is now logged in seconds per request for the front end web server.
>
> Just watching:
> $ tail -f -s 0.1 /var/log/lighttpd/current-access.log | grep -v ' [0-9]$'
>
> I noticed a lot of the longer than 9 second requests were for js and css.
>
> Firebug indicates that we aren't doing HTTP compression,
>
> vendor.js:211k
> all.css: 100k
> all.js: 129k
> ----------------------
> total: 440k
>
>
>
> after gzip:
>
> vendor.js: 62k
> all.css: 19k
> all.js:31k
> ----------------------
> total: 112k
>
> This is very much worth doing.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openlibrary/+bug/579606/+subscribe
>

--
Samuel Stoller
<email address hidden>
mobile: [phone]
skype: samuel-archive

[Anand Chitipothu (anandology)]

On 25-May-10, at 12:45 PM, samuel-archive wrote:

>
> Nice!
>
> while looking at the speedup, i noticed that
> vendor.js is lacking a cache-control header,
> thus requiring a 304 cycle on each page load ...

I'm in the process of enabling mod_expire.

We add md5 as the query argument when constructing the URL. That
enables us to specify infinite max-age.