Steve Gillmor comments on TechCrunch today that Comcast’s caps on bandwidth may finally drive people from the land of torrents, and to the land of streaming. [here]

While I agree that the promise of streaming is long overdue, there is the one area that streaming still can’t fill: The mobile viewer. I don’t mean folks on mobile phones, although with the growth of 3G in the Americas (Europe and Asia laugh at us in the area), the mobile market will become more important.

No, I am referring to the mobile, laptop-using traveller, mainly the business traveller, although leisure travellers are starting to take their laptops with them more often. Streaming doesn’t work on the road, in a hotel with a crappy connection, in an airport, or somewhere were the 3G isn’t 3G enough.

While streaming will become more prevalent, it won’t unseat the culture of Torrents for a few years yet. It will happen. But affordable, reliable connectivity saturation across the Americas has to occur first. And, in some ways, Comcast and the other providers are the ones hampering this process.

The focus of the connectivity providers on their dinosaur cage-match with the FCC has left them ignorant of the asteroid screaming toward them. In order to create a streaming market that they can profit from, they have to open the pipes, lower the costs, and increase the options for the consumer of their Internet/bandwidth services. If the connectivity they provide to the consumers can’t support the desire for the streaming economy, the Torrent reality will not fade away.

Got my invite to Joost today. Downloaded the app and tried to use it.

Channel selection is lame.

Response is slow.

And even on my reasonably powerful laptop, the memory, CPU and network usage went through the roof.

Yup. Uninstall.

Tags: Joost

It’s always funny when somewhat tech-savvy folks purposely make their bandwidth bills higher than they need to be.

Here’s TechCrunch’s HTTP header response.

HTTP/1.1 200 OK
Date: Tue, 16 Jan 2007 16:02:23 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8 mod_ssl/2.2.3 OpenSSL/0.9.8c
X-Powered-By: PHP/5.2.0-8
X-Pingback: http://www.techcrunch.com/xmlrpc.php
Status: 200 OK
Transfer-Encoding: chunked
Content-Type: text/html; charset="UTF-8"

Port80 Software’s Compression Checker gives us some idea how much bandwidth Mr. Arrington, et al. could save just by activating this little feature, which comes baked into Apache 2.2.x.

Turn. On. Mod_deflate.

This paper is an extension of the work done for another article that highlighted the performance benefits of retrieving uncompressed and compressed objects directly from the origin server. I wanted to add a proxy server into the stream and determine if proxy servers helped improve the performance of object downloads, and by how much.

Using the same series of objects in the original compression article[1], the CURL tests were re-run 3 times:

1. Directly from the origin server
2. Through the proxy server, to load the files into cache
3. Through the proxy server, to avoid retrieving files from the origin.[2]

This series of three tests was repeated twice: once for the uncompressed files, and then for the compressed objects.[3]

As can be seen clearly in the plots below, compression caused web page download times to improve greatly, when the objects were retrieved from the source. However, the performance difference between compressed and uncompressed data all but disappears when retrieving objects from a proxy server on a corporate LAN.

Instead of the linear growth between object size and download time seen in both of the retrieval tests that used the origin server (Source and Proxy Load data), the Proxy Draw data clearly shows the benefits that accrue when a proxy server is added to a network to assist with serving HTTP traffic.

	MEAN DOWNLOAD TIME
Uncompressed Pages
Total Time Uncompressed — No Proxy	0.256
Total Time Uncompressed — Proxy Load	0.254
Total Time Uncompressed — Proxy Draw	0.110
Compressed Pages
Total Time Compressed — No Proxy	0.181
Total Time Compressed — Proxy Load	0.140
Total Time Compressed — Proxy Draw	0.104

The data above shows just how much of an improvement is gained by adding a local proxy server, explicit caching descriptions and compression can add to a Web site. For sites that do force a great of requests to be returned directly to the origin server, compression will be of great help in reducing bandwidth costs and improving performance. However, by allowing pages to be cached in local proxy servers, the difference between compressed and uncompressed pages vanishes.

Conclusion

Compression is a very good start when attempting to optimize performance. The addition of explicit caching messages in server responses which allow proxy servers to serve cached data to clients on remote local LANs can improve performance to even a greater extent than compression can. These two should be used together to improve the overall performance of Web sites.

[1]The test set was made up of the 1952 HTML files located in the top directory of the Linux Documentation Project HTML archive.

[2]All of the pages in these tests announced the following server response header indicating its cacheability:

Cache-Control: max-age=3600

[3]A note on the compressed files: all compression was performed dynamically by mod_gzip for Apache/1.3.27.

I finally tired of running my own blog server, and since most folks use the feeds, I figure I will abuse Matt Mullenweg’s bandwidth rather than my own.

Welcome back?

I have been running the GrabPERF Compression and Performance study for less than a week, but I thought that I should share some of the initial results with everyone.

As you can see above, the byte transmission savings gained by some sites is pretty astounding. Google News sends a pages with a median weight of near 31,000 bytes when compressed; but when compression is disabled on the client, this jumps to over 139,000 bytes.

What is interesting is that the performance gains don’t look truly significant. However, they compressed pages are faster, and have the added benefit of costing the site less, as bandwidth costs count by the byte (I know it’s more complicated than that, but for now, let’s assume a fantasy world).

I will continue to monitor that results and will close the measurements after 14 days and write up a final report.

Technorati Tags: GrabPERF, Web+performance, Web+Compression, HTTP+Compression, Performance+tuning, GZIP

Dear PodTech:

Use HTTP Compression. It’s built into Apache/2.0.

HTTP/1.1 200 OK
Date: Tue, 13 Jun 2006 15:30:24 GMT
Server: Apache/2.0.53 (Fedora)
X-Powered-By: PHP/4.3.11
X-Pingback: http://www.podtech.net/xmlrpc.php
Status: 200 OK
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Probably save you some bandwidth and improve your performance, which is in the tank right now.

Podtech Live Web Performance

Best of luck.

Technorati Tags: PodTech, GrabPERF, Web Performance

Yesterday I was on a call with a customer who flat out stated that 55% of their bandwidth was consumed by applications pulling RSS feeds.

Does your company have a grip on just how much continual background noise RSS feeds inflict on your Web servers?

Technorati Tags: RSS, Web performance, bandwidth

I guess bandwidth doesn’t matter to Yahoo. They don’t use gzip/HTTP compression any more.

Ok, not completely true. It’s there on the Portal Page. But nowhere else.

<sigh>

I give up.

Dear Level3:

Your homepage is full of useless empty spaces, including a very large screen full of empty space after the server response. Have you not heard of HTTP Compression?

At least I know you are using what used to be called ColdFusion to manage your content; ColdFusion is notorious for leaving large gaping holes in a Web page web the application code is stripped away for presentation.

Why would I by transit from a company that seeks to maximize their own bandwidth usage, not conserve it?