[poll id="2"]

Part of the problem with making a lot of East to West trips across the US is that the flights back are a nightmare for timing. You either lose most of a day or have to take a red-eye.

Well, taking the red-eye has only one advantage: you get to camp in the airline lounge and get some work done that you have been too tired/jetlagged to deal with.

I am in the United Red Carpet Lounge. It is 18:33 PDT, and my flight boards at 22:00 PDT. I have been here since 15:00 PDT. I have caught up with a client project, completed my (dreaded) weekly timesheet, booked accommodation for my Columbus, OH trip, and tidied up an analysis script that I use to process client measurement data.

Seems odd that this is the most productive time of the week.

This trip is a 48-hour turnaround from Boston to LA to finish up the project for a large client. The first half was handled by some colleagues, and was detailed here.

Then,when I get home, I have to go to NYC (Long Island City actually) for the day on Monday. And, as I mentioned above, Columbus which is set for the middle of the month.

Compared to some jet-setters out there, this is nothing. But I travelled so much between August 15 and November 15 that I went from 2,000 miles on United to well into Premier (24,000+ miles). This trip makes the fourth cross-country trip in 2.5 months. Not bad for a homebody.

I have three more hours. Think I will sit back and watch Trois Couleurs: Blanc.

I have finally given up on Trillian releasing a new version anytime before the next ice age, and switched to the the messenger client formerly known as GAIM, now known as Pidgin.

Solid, functional, and showing signs that it is in active development. Unlike Trillian, which is slowly becoming the Duke Nukem Forever of messenger clients.

I’m sorry, but promising a cool new product, and then not letting anyone try it leads to scores of new Pidgin users.

Tags: Pidgin, Trillian, Duke Nukem Forever

The client visit this week (and don’t expect too many details) was to MySpace. It is interesting to get an inside perspective on their performance challenges, as well as their beyond unique infrastructure.

I am bagged, and off to write up a document for another client.

Tags: LA, MySpace, myspace.com

I did a six-hour presentation / training seminar today, with an encore for a second group tomorrow.

I now realize how frightfully out of practice I am.

I used to do these kinds of events all the time up until 3 years ago. Tonight, my voice is shot, I ache all over, and it feels like my face muscles are injured from smiling and looking positive.

And I liked it.

Tags: presentation, clients, New York, out of shape

I am writing up a client presentation for next week, and I just realized just how flawed Internet Explorer is. Microsoft claims that the browser is standards compliant. Yet it still doesn’t support HTTP pipelining.

And the frustrating part? They won’t tell us why. I have my suspicions, which include TCP stack issues and a flawed HTTP handling mechanism that is still based on Windows 95 architecture, but an explanation from Redmond would be nice.

Every (and I mean every) other browser can do this.

Microsoft, it’s time you detached your Web browser from your OS, like you’ve forced everyone else to do.

Tags: HTTP, pipelining, RFC 2616, Firefox, Opera, HTTP Pipelining, Internet Explorer

Going to Chicago for a client meeting tomorrow. Use Skype to reach me, or show up at Topolobampo tonight around 20:00 (8:00PM) CST.

Flying JetBlue into Columbus tomorrow to see a client in the Cincinnati are on Thursday.

Not that anyone ever checks in, but if GrabPERF goes poof, it may be a while before I get to it.

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 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