What is Digg?26 Comments
- kyriakos, on 10/12/2007, -0/+9.. but with an impact on CPU load..
well you cant have it all.. - sahaskatta, on 10/12/2007, -1/+8another thing you could do is BLOCK the FASTERFOX extension (which prefetches like crazy)
http://www.skattertech.com/2006/02/how-to-block-fasterfox-requests/
after enabling this i am using 10% less bandwidth a month than I was before - badriram, on 10/12/2007, -0/+4Actually overall response times increase, as you can have caching of the compressed files, (well i do under IIS, cant see why apache cant), and since the files are smaller, you tend to have lower bandwidth usage, lower processing power and faster transmission of files.
So essentially if you compress then cache, and invalidate cache on file change, you can have best of all worlds - negativefx, on 10/12/2007, -0/+4Actually, with the amount of CPU saved by handling cached & compressed pages, the overhead required by compression is greatly offset.
- mcotis, on 10/12/2007, -0/+3Configured it on my website, and seems to save at least 20%.
- bugfaceuk, on 10/12/2007, -1/+3Generally no impact on CPU load, as managing longer persisting connections is also a causal factor for high CPU loads. In our testing we reduced bandwidth and CPU load through its use.
- tablatronix, on 10/12/2007, -0/+2What about response times ?
- stuffhappens, on 10/12/2007, -0/+2Look, I know this is going to get minus dugg to pieces but why the f*ck are we highlighting the standard features of a product that has been around for years?
This is basic stuff for any Web administrator - but so what? I am learning about Voice Over IP and Asterisk but I'm not going to submit every bl**dy new command or feature I read about.
. - Wootery, on 10/12/2007, -0/+2"well you cant have it all.". The obvious solution is to have Apache compress them and store the compressed versions as well, rather than compressing every request.
Not saying this is possible (yet), I have no idea, but this method strikes me as amazingly inefficient. - Assad, on 10/12/2007, -0/+2When the client browser sends the Accept-Encoding request-header to the server stating that it does support compression, the server decides if it will compress the requested file based on it's configuration and then send it to the client. If it's static content, you can pre compress it and configure mod_deflate to use it and don't compress in on-the-fly, if it's dynamic content, then it can only compress it on-the-fly.
When the server sends the compressed content back to the client, the client will decompress it automatically and show the file to the user as if it wasn't compressed at all.
Accessing local compressed files has nothing to do with mod_deflate or HTTP/1.1, never tried it. You can gzip a html and check what happens when you try to open it. - 0siris, on 10/12/2007, -1/+3what the deal with all these people posting random characters?
- Heymoe, on 10/12/2007, -0/+1Is this what Netscape and People PC ISP's charge dialup users $5.00 a month for under the name of "browser accelerator", or do they route you through a caching proxy to add a bit more speed?
- pabster, on 10/12/2007, -0/+1Because it is (primarily) a Linux-based solution. Of course, most people are too stupid to realize Apache is available for other platforms (like Windows.)
Digg users love anything Linux or Linux-based and always put this kind of ***** up. - CannonBallGuy, on 10/12/2007, -2/+3Wow, gzip & base64... nice! :D
- MrUnknown, on 10/12/2007, -0/+1Your connection is routed through a proxy. The proxy compresses text AND images. The images part is what causes the connection to be "faster"
of course to get the 5x increase, the compression done to an image makes it impossible to tell what the image was before. You can choose a middle ground that actually does increase the speed of the internet while letting you see the images, but the increase isn't much. maybe 2x.
I prefer to disable images every once in a while to visit image-stuffed news sites. - starthorn, on 10/12/2007, -0/+1In these days of 3GHz+ computers with multiple processors, and even multiple cores in those processors, CPU is a *lot* cheaper than bandwidth.
Even if that weren't the case, though, I've found the performance hit to be negligible. I've been using this for quite some time now, and mod_gzip on Apache 1.3 for 5 years. It's more than worth it. - 4zumanga, on 10/12/2007, -0/+1This applies gzip to the HTML/XML.
Out of interest, has anyone ever seen a system, even offline, that will try and compress HTML by removing all the redundant stuff (comments, spaces, etc. etc.). I've often thought that could be quite useful... would make it gzip better too I expect, so the two would work together well. - got-haggis, on 10/12/2007, -0/+1how does the compression work exactly? For example, is it possible to compress html files to display offline? Is it possible to somehow manually (or through script) to compress these HTML files (lets say they are on a CD-ROM for example) and the browser will automatically decompress them?
- shadedream, on 10/12/2007, -0/+1I think the "browser accelerators" are mostly just using a caching proxy... I could be wrong though
- Assad, on 10/12/2007, -1/+1Been using it since apache2 was released... and mod_gzip before that on the apache1.3 . Saves me around 50% of bandwidth which corresponds to hundreds of thousands of dollars in the last 5 years.
- Wootery, on 10/12/2007, -1/+1And advanced network setting tweaks for Windows. And turning off QoS.
- Restless, on 10/12/2007, -3/+1H4sIAAAAAAAAA/Px91GwCgAAxIq2tAYAAAA=
- Ryuuzaki, on 10/12/2007, -4/+2Yes, you can. There's this algorythm called LZO: http://en.wikipedia.org/wiki/LZO
...which has some degree of compression with nearly negligible CPU usage. The problem would be for support to make it into webbrowsers. - Ryuuzaki, on 10/12/2007, -9/+0-deleted by poster-
- Ryuuzaki, on 10/12/2007, -13/+2H4sIANx2iUQAAyXLsQ2AMAxE0Z4pjoouezACpUWOEAkcyXaQ2J5INL96fz3wtr4YYZRctSDO
6rjpLoUpJexNi0n0S6I29Rnb7/0WC9rwoiOEPLTxIPfMNH3e6YD3WQAAAA== - inactive, on 10/12/2007, -19/+1BEGIN>>QRQAAIEJJAZXMCKDDIEJDOFHWWWWHFOSSNCNCIWUDHHDHOWOWHCUCUWHAHAAQOEIEJALSKDJZOXPCOXIIIXICUXYSUWHABSBDNCMZXXNSYSGDYWYYQQQTDTTTYDBSNDBFHGGTWYDTSYSYAAAUSDGDUEVEVEVFMSSUDEEKAUSUSUUDHEHEEEVEDDUAGDGGGQGQDDDDQDDDQDDUIIZKXJCOAOOSJWEJEBFJAKAAAIAHSUCBWUWDHGFIAWVAIQUDASD
© Digg Inc. 2009
— Content created and posted by Digg users is