You are not logged in. Please login or register.
TuxFamily's forum → Suggestions → [OK] enable gzip/deflate compression for Apache
Hello,
I suggest enabling gzip/deflate compression on TuxFamily's Apache webserver so that we can reduce bandwidth consumption.
For example, here are the bandwidth savings for the http://tuxfamily.org/en/about webpage:
Actual Page Size: 12 KB
Size if Gzipped: 4 KB
Potential Savings: 66.67%
See these instructions on enabling mod_gzip or mod_deflate for Apache.
Thanks for your consideration.
Hi,
Well I am not sure whether this is good or not.
First, this can only apply on text/html or text/plain contents, so here is the data that will not be compressed anyway on the page you took as example:
sitetf/trunk$ du --si --apparent-size -c templates/tf2/gfx/footer_bg.png templates/tf2/gfx/header_bg.png images/logotfsmall.png images/langs/*.png images/partners/*.png images/people/*.png images/people/*.jpg templates/tf2/gfx/*entry.png templates/tf2/gfx/button* | tail -1
161k total
so... 161k + 12k = 173k total ; savings: 12k - 4k = 8k ; 8/173 = 0.0462
Woa 4.62% of bandwidth saved, this is amazing.
Yes I know about caches of images and such, so perhaps it would be better to make this text/html cacheable by adding necessary headers to allow the web browser to do that rather than compressing it.
Next, and this is much more important that saving bandwidth, compressing data means that we use power on our side to compress the data and power on your side to uncompress the data. However using more bandwidth consume slightly more power in routers. So, compressing the data would be a good thing if the power saved in routers is more than power used on both sides to compress and uncompress the data. I would not conclude too quickly, but I have a good idea about the answer.
Sylvain
Thanks for considering my request.
Regarding text/html caching, I believe Apache sends Last-modified headers to browsers by default. So when I refresh the same webpage in my browser, it will negotiate with Apache and only download the webpage if it has been modified since my last visit.
---
Regarding power consumption, if it contributes more to TuxFamily's operation fees than bandwidth consumption, then I suppose it is alright to leave things as-is. But I wonder: gzip is a highly optimized compression algorithm, and computers are so capable (and underutilized) these days. Perhaps it would be more power-efficient to compress/decompress the data in the unused CPU cycles than to send/receive lots and lots of uncompressed data?
---
Regarding my request, I asked for compression primarily because the home pages of my software projects are large, monolithic XHTML documents. With many unique visits per month, these files consume a lot of bandwidth IMHO. mod_gzip or mod_deflate would benefit them greatly:
http://snk.tuxfamily.org/lib/erbook/ is not gzipped
Actual Page Size: 237 KB
Size if Gzipped: 51 KB
Potential Savings: 78.48%
http://snk.tuxfamily.org/lib/inochi/ is not gzipped
Actual Page Size: 171 KB
Size if Gzipped: 41 KB
Potential Savings: 76.02%
http://snk.tuxfamily.org/lib/rassmalog/doc/guide.html is not gzipped
Actual Page Size: 113 KB
Size if Gzipped: 23 KB
Potential Savings: 79.65%
http://snk.tuxfamily.org/lib/ruby-vpi/guide.html is not gzipped
Actual Page Size: 200 KB
Size if Gzipped: 41 KB
Potential Savings: 79.5%
Thanks for your consideration.
Hi,
Thanks for considering my request.
You are welcome ;-)
Regarding text/html caching, I believe Apache sends Last-modified headers to browsers by default. So when I refresh the same webpage in my browser, it will negotiate with Apache and only download the webpage if it has been modified since my last visit.
Yep, it depends whether the webpage is dynamically generated or not, today almost all websites use dynamically generated webpages, so each app should generate a Last-modified header in the HEAD request.
Regarding power consumption, if it contributes more to TuxFamily's operation fees than bandwidth consumption, then I suppose it is alright to leave things as-is.
Bandwidth consumption fees are ridiculous next to power fees.
But I wonder: gzip is a highly optimized compression algorithm, and computers are so capable (and underutilized) these days. Perhaps it would be more power-efficient to compress/decompress the data in the unused CPU cycles than to send/receive lots and lots of uncompressed data?
Well, I would have admitted that 10 years ago, nowadays computers are able to put their CPU in idle state, and even to change at which frequency they run. Computers are not underutilized, they just use power when there is a need, this is almost perfect on laptops, less on regular desktops. Although while former TTL chips used a lot of power in stable states, this is not the case for CMOS chips which only use power on states changes, yep, this is quite a way back 20 years ago ;-)
And if clients' computers are underutilized, this is clearly not the case of our servers. Compressing data on our side will add a new load on the already heavily loaded one. Based on the fact that compressing the data use a lot more power than uncompressing the data this is clearly not a good opportunity for us.
Regarding my request, I asked for compression primarily because the home pages of my software projects are large, monolithic XHTML documents. With many unique visits per month, these files consume a lot of bandwidth IMHO. mod_gzip or mod_deflate would benefit them greatly:
Well, this is quite an uncommon case on TuxFamily, almost all websites now use CMS which generate dynamic contents, and yep, we would prefer to host only static websites, but the time is over for those ;-)
Also, sending data without compressing them may allow us to do that without copying the data to user-land and without copying the compressed data back to kernel-land (sometimes called as zero-copy). Well, apache don't do that yet, but lighttpd, which is used on TuxFamily's download repositories, and other does.
Sylvain
Good, then let us leave things as they are. Thanks for taking the time to explain all this.
I felt guilty that my project homepages were consuming too much bandwidth (and perhaps contributing too much to TuxFamily's operating fees). TuxFamily is such a generous service and I would hate to burden it: "Do not bite the hand that feeds you", as the saying goes.
I am relieved to know that this is not a problem, and will continue to develop my open source projects in peace. :-)
Cheers!
Hi,
Good, then let us leave things as they are. Thanks for taking the time to explain all this.
You are welcome ;)
I'm glad to explain why some of TuxFamily choices are not only based on purely computer outlook, like ethic or power consumption, and also that choices are often made from a wide thinking.
I felt guilty that my project homepages were consuming too much bandwidth (and perhaps contributing too much to TuxFamily's operating fees). TuxFamily is such a generous service and I would hate to burden it: "Do not bite the hand that feeds you", as the saying goes.
I am relieved to know that this is not a problem, and will continue to develop my open source projects in peace. :-)
No problem about that, use what you need ;-)
By the way, we always looove to read this sort of gratefulness, this doesn't happen very often, sooo ;-)
Sylvain
TuxFamily's forum → Suggestions → [OK] enable gzip/deflate compression for Apache