New Breed Of Web Accelerators Actually Work

axlrosen writes "Web accelerators first came around years ago, and they didn't live up to the hype. Now TV commercials are advertising accelerators that speed up your dial-up connection by up to 5 times, they say. AOL and EarthLink throw them in for free; some ISPs charge a monthly fee. Tests by PC World, PC Magazine and CNET show that they do speed up your surfing quite a bit. They work by using improved compression and caching. The downside is they don't help streaming video or audio." And they require non-Free software on the client's end, too.

Comments

I still don't understand

[Anonymous Coward]

Why so many content providers aren't using gzip compression? The cpu time required is MUCH cheaper than the bandwidth, AND it makes users happiers because they get it faster. Oh, and it's free (for Apache anyway) and easy to set up. It even works with 99% of browsers these days.

But really, why?

[agent dero]

This seems like a really niche market nowadays. Not _too_ many people that need fast internet, that could use this, don't have broadband availible. The one key thing is price, which is even starting to get iffy.

Something like $10-20 monthly for "speedy" earhtlink dial-up, or an extra $10-20 slapped on my monthly cable bill for broadband? (Charter Communications, they suck anyways)

I guess if you need to read /. or pr0n that much fast, it works, tell me if I am wrong, but I am seeing a small market for this much hype

Compressing the already compressed?

[insecuritiez]

They compress the packets of data. Where will this help? In compressible places that aren't already compressed. Such as the HTML markup for webpages. This wont help already compressed JPGs, or already compressed MP3s or already compressed ZIP/GZIP files or already compressed videos (MPG/AVI/ASF). So is this really going to help much? Sure, there is always going to be a small percent of space (and therefore time) saved even transferring these formats. Is it going to make a 5X difference? No. Is it going to make a noticeable difference? It's unlikely but possible. The only way this "new technology" is going to help is if you are a dialup user without broadband options.

because IIS's is garbage

[DrSkwid]

mod_gzip is manna from heaven

I turned mine off by accident once and got a phone call from the co-lo wanting to know why I was suddenly maxing out.

gotta love that 70% saving.

Re:because IIS's is garbage

[Jerf]

Of course, I should also add that both numbers would be a lot lower if the Slashcode theme remotely resembled web standards instead of horrendous amounts of nested tables and "spacer" graphics, but that's getting off-topic.....

Actually, try downloading your page, copying it, gzipping the original, cleaning up the copy to your specs, gzipping that, and comparing the two file sizes. While you may kill a lot of text in the uncompressed version, I would strongly suspect you'll find that the gzip'ped version saved much less then you think.

Those "spacer gifs" that take up perhaps 100bytes apiece in the original file (perhaps a bit generous) will compress away down to very little (if there are several near each other, they may literally compress down to a handful of bits after the first one), whereas the story text compresses much less well.

If you're compressing things, XML, CSS, and a lot of other things that look awfully redundent in plain-text are suddenly downright bandwidth-efficient technologies, being dwarfed in their compressed representations by the plain-text payloads. This is one of the reasons that fundamentally XML is so cool; you get human readability, but for the very small effort of invoking gzip or similar compresion technology, you also get something that is very nearly as bandwidth-efficient as possible, because compression technologies dynamically determine the best binary encodings for such messages (including their plain-text payloads), whereas supposed "efficient" binary protocols may actually waste a lot of space. (Compressing the both of them may equalize them, but the binary file, perversely, will still be "harder" to compress, even with nearly the same information in both files.)

How compression behaves is not necessarily intuitive.

Squid & mod_gzip

[chill]

ISPs could simply put some squid caches between the net and their dial-up banks. Turn mod_gzip on and you'll accomplish a lot of the same thing.

Instead of having to traverse the Internet, with all the associated latency, pages are pulled locally - 1 hop away. Pages are also compressed.

A better way would be to figure out how to transfer pages via CVS, so only .diffs came across. :-)

Re:Squid & mod_gzip

[Anonymous Coward]

Does that actually exist, a mod_gzip for Squid?
There is a mod_gzip for Apache...

Re:Squid & mod_gzip

[burns210]

on your cvs comment, it sounds alot like the rsync solution... rsync copies files over the net. but if the file already exists, it will only copied the sections of the file that are change(10% maybe) and keep the other 90%... That sounds like a great feature to have for the cacheable proxies.

Re:Squid & mod_gzip

[chill]

on your cvs comment, it sounds alot like the rsync solution...

Doh!

I meant rsync. I use it to sync websites on multiple servers.

Thanks.

Hooray...

[-Grover]

You can get the same thing you looked at yesterday 5x faster!!

Caching and compression will only get you so far before lossiness (sp?) kicks in and you start getting garbage, or caching works so well you get the same page every time you load it.

Get on the bandwagon and chip the money for Broadband if you're looking to boost your speeds. If you can't get a/v any faster, really, what's the point?

Low bandwidth main pages becoming less and less prevalent so it's not going to do you much anyway, plus, you're still paying for it...

Semi-real, maybe

[Empiric]

Okay, so GIFs, JPGs, streaming video, ZIPs, and compressed .EXE installers are all already compressed near to their thoretical limits.

[Puts cynics hat on]

The vendors mentioned in the PCWorld article seem to be treading dangerously close to copyright infringement by compressing other people's content on their servers to be pulled through their browser proxy.

NetZero and Earthlink apparently force you to use their proprietary internet-access layer, so how are we sure their extra-cost "Super" speed isn't just normal internet speed, and their "Base" speed isn't just slowed down by the interface layer?

[Takes cynics hat off]

The only thing here that seems like it would be genuinely useful is HTML compression... surely there is/will-be an Open Source solution for this. Maybe a new MIME type, e.g. text/html.compressed? Then it could be implemented on both the browser and server side, and this would have far greater impact. This could be implemented either in the browser itself or in a lightweight proxy like Proxomitron. Anyone? Anyone?

Use faster web servers

[peel me a grape]

The web could be faster if web server admins used faster web servers. Zeus Web Server instead of Apache, for example. The Holy Grail of web serving seems to be "good enough is good enough, and performance is someone else's problem".

Squid

[Helmholtz]

Personally I've found putting my modem on a box with a large amount of disk space and running squid to be extremely useful. In between the agressive caching and blocking banner ads, most of my web browsing doesn't seem very slow at all.

Of course when it's a new site chock full of graphics, or I'm doing binary downloads, I'm painfully aware of my modem's limitations. But for general surfing, sometimes it seems almost as good as the friends' broadband.

Re:They aren't really that great.

[Reziac]

AOLpress makes the cleanest, most legible HTML you'll ever see (better than most people bother with their hand-crafted HTML, in fact). It's also utterly anal about correct tags. I use it as a validator and code beautifier even when I've built the page in something else. Between that and its ability to work as a browser (a huge timesaver when a site is all unique pages and you need to follow links back and forth between several of 'em as you edit), it's completely ruined me -- now I expect *every* editor to do as well :)

Save As HTML woulda been my first thought too.. except knowing the kark that Word thinks is HTML, I'd probably do this instead: save as WordPerfect 5.1, then (assuming I didn't have WP available to cut the middleman) I'd run it thru one of the WP-to-HTML tools, which usually do pretty well on tables, then load and save in AOLpress to clean up artifacts and mismatched tags. And when it magically appears on the website well before the deadline, the boss thinks you're a genius. :)

RabbIT Proxy

[DA-MAN]

Ah, you mean like the RabbIT proxy. Personally I run this on my box on a t1 and use it whenever I am stuck with all but dialup.

Speeds things up so much, it's not even funny. Although it does require that you have a machine on a decent, faster than dialup connection to make it work well.

Can't compress twice

[fm6]

I would prefer more browsers to use gzip for retrieving web pages.

I might be wrong, but I'm pretty sure this would have not help dialup users at all. They're already using hardware data compression in the modem. When you're using lossless compression, there's an absolute limit as to how much compression you can get -- and you can't get around that limit by running your data through multiple compressors.

(I should check this out by timing various downloads, but I'm too lazy. Somebody else can prove me wrong!)

So why do JPEG files with "more" compression download faster? Because JPEG is a lossy format: when you increase the "compession" you're not encoding data more efficiently, you're throwing data away. Depending on the image, you can do this and still end up with something that looks the same. But push it far enough and you end up with crap.

Re:Can't compress twice

[HeghmoH]

You're making the incorrect assumption that all lossy compression is equal.

Modem compressors work very, very poorly. This isn't just because the people who come up with them suck, there are fundamental problems with doing compression in the modem. In order to avoid introducing really horrible latency, you have to compress the data in fairly small chunks. You can't wait for 50k of data to arrive from the computer and compress it all at once. Yet any decent compression scheme will achieve better compression ratios on longer chunks of data than shorter ones in non-pathological cases. So you have a modem which is stuck trying to compress a hundred bytes at a time, and a web server which can compress all 100k of page at once, and you have a significant difference in size. Also, gzip runs on a computer with a truly mind-boggling amount of number-crunching power available compared to a modem, which has a CPU just powerful enough to handle complicated commands like "ATH". With more CPU power, you can achieve better compression ratios.

In the end, modem hardware compression is basically a hack, and mostly a worthless one. There's a reason why everybody who distributes a file for download compresses it first, and it's not because it makes the file look prettier.

Well, actually . . .

[erikharrison]

I hate to conflict with the general Slashdot opinion that this technology is somehow bad, but the truth is this stuff rocks

I've seen Internet Connection's acheive compression rates and acceleration rates breaking 130Kbs (equivalant).

We've talked some about compression rates, but there is more to it than that. This stuff does:

• Serverside image regression. Images have their quality reduced (at variable levels) on the server, thus reducing download times. And with good IE integration you can pick individual images or pages to restore to full quality.
• Persistant connections. And by that, I am refering to TCP/IP sockets. A surprising amount of traffic on a dial up connection is renegotiating TCP sockets, because the reduced bandwidth results in lots of TCP/IP time outs. The ISP's server is on a broadband connection, so it can maintain those TCP sockets, and the only thing the client has to maintain is a single socket to the ISP's accellerated proxy. This cuts out that additional TCP overhead.
• Smart caching. These systems usually maintain a seperate cache from the browser. This cache is smart. It rates documents based on the frequency of download, and removes those that aren't often viewd, while preloading highly viewed images and documents into memory on load to increase performance.
• And finally, ridiculous compression rates, the natural evolution of the good ol' v.42 related standards.

The first two require a proxy server setup, the second two are just plain good ideas that haven't made it into the wild. For example, the smart cacheing could be implemented by Moz, or even by a Firebird extension. The last could be handled by a certain standards body implementing much more aggresive changes in terms of compression instead of features like the ones introduced in the v.92 standard.

Optimizing pages

[Anonymous Coward]

Web accelerators seem to do *something* to speed up typical pages. A better, though not so easy way, is to have web designers push their pages through something to clean them up. I believe that a great part of the problem are these web design packages that pepper thousands of nbsps throughout a page, dozens of 1x1 gifs, unnecessary tags, comments, etc.. Take a look at Google's source code. Every byte on their page is optimized. Also, designers should be made aware of compression levels. I've seen lots of sites with large images that have been "scaled" by adding WIDTH and HEIGHT tags but still have huge actual resolutions. Many don't know about the negligible tradeoffs for some images that increased compression can offer.

Speed up your site and cut bandwidth use right now

[ChaosDiscord]

One step most of these proxies is doing is compressing HTML files. HTML is highly redundant, so compression can save alot of space. However, it's silly for the proxy to do the compressing. Instead web site owners can do the compressing! Transferring pages gzip compressed is part of the standard. No special software is needed by end users. A 3:1 reduction in bytes transferred for your web pages (the HTML itself) is a reasonable minimum. The result is that you use less bandwidth and end users get a faster web site! Every mainstream browser supports this, and those browsers that don't support it will automatically get the uncompressed version. If you're using Apache, you'll want mod_gzip to automatically compress transfers. (You can fake the effect with MultiViews, but it's a hassle to maintain two copies of every HTML file.)

(Yes, I know I don't practice what I preach. I'm working on it.)

Evil...

[SharpFang]

Harvest all the links on a webpage, cache them on disk while you view the page content, if you still don't go anywhere, harvest links on the cached pages, and so on. If you type some URL and go elsewhere, discard everything.
Results for you: You click on a link and you have it immediately - from harddisk cache.
Result for others: A major part of the bandwidth is wasted, everyone's connection gets slower.
Effects: Everyone installs accelerators to have the net working faster. Bandwidth usage jumps 10 or so times, prices rise, connection speed drops far below what was before the accelerators. Nobody gives up the evil accelerators because without them it goes even slower.

It's called "social trap".