In comp.os.linux.advocacy, Larry Qualig
<lqualig@xxxxxxxxx>
wrote
on 9 Jun 2006 12:44:27 -0700
<1149882267.247853.43900@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>:
>
> Ray Ingles wrote:
>> On 2006-06-09, Stephen Fairchild <somebody@xxxxxxxxxxxxx> wrote:
>> >> It is interesting to contemplate the tradeoffs. I would presume that
>> >> mod_deflate consumes CPU at the server side (and, to a lesser extent,
>> >> the client side), to trade off bandwidth, which can be expressed as
>> >> power consumption throughout the world as the packets wend their way
>> >> through various routers.
>> >>
>> > I have not looked into this and I am too lazy to research that link but I
>> > suppose it would be neat if among its capabilities is the ability to choose
>> > to compress whenever there are spare cpu cycles.
>>
>> My understanding is that the compressed versions are stored in a cache,
>> so the real CPU hit is only the first time a particular file is served.
>>
>> Many web browsers support gzip compression, too. Some webservers look
>> to see if there's a ".gz" version of a file with a later timestamp than
>> the original, and if so they serve that (with appropriate headers).
>> Minimial CPU overhead for that one.
>
> This works for static content but for dynamically generated web pages
> you'll still need to do the compression on-the-fly. The main problem
> with this is that on most websites the actual page definition itself
> (the HTML) is relatively small. It's all the graphics on the page that
> eat the bandwidth. A single small to medium sized image is usually as
> large as all of the HTML on the page.
Also, unless the graphics are BMP or SVG, they're *already* compressed.
(SVG is rare and BMP is nonstandard.)
[.sigsnip]
--
#191, ewill3@xxxxxxxxxxxxx
Windows Vista. Because it's time to refresh your hardware. Trust us.
|
|
