Song of The Day: Inside Out - Artist: Eve 6

There was an interesting read recently on Slashdot from a Google engineer, Aaron Hopkins (i.e., that’s what the webpage indicates). The blog entry covers improving the user experience of web-based applications through faster page load times.

It mainly caught my attention because of Aaron’s use of simulation and graphs to model protocol efficiency. This is something in which I’ve been interested for a while when thinking of better mechanisms to determine effects of web-based designs a priori. For example, how many times does a product hit beta or production and then the team goes, “Oops! It’s too slow. Work weekends until it’s better.” Well, maybe that’s what the biz says and makes the dev team do :).

Many aspects of the essay weren’t new to me, being involved with various web acceleration efforts at AOL; however, since there is surprisingly little information concerning real-world simulation and optimization, it’s a good read and contains fresh information and tips, which are worthwhile.

For me the summary boils down to the following with a few additional tips of my own:

  • Upstream bandwidth can be a bottleneck, perhaps surprisingly, but it happens with all those request headers and cookies.
  • Persistent connections improve performance, that’s why HTTP 1.1 has them as the default. Avoid closes after each transaction at the origin server and user-agent.
  • Rally for pipelining in browsers. I support this, but would like to have tweaks to the rallying with things like out-of-order responses. Pipelining can be so application specific that it can cause as much harm as good.
  • Possibly use “branching” between static and dynamic content.
  • Cache as much as one can. Use Expires and Cache-Control directives. So many performance ails start with a malformed or missing Expires header (e.g., Expires: Thu, 2 Nov 2006 09:50:39 GMT versus Expires: 0) for HTTP 1.0 or an incorrect or missing Cache-Control: max-age=86400 for HTTP 1.1. Avoid cache algorithm heuristics with Last-Modified and subsequent If-Modified-Since or IMS checks.
  • Peering: a page served closer to the user is typically faster.

Couple of things I didn’t see that I would suggest:

  • Gain visibility into what is happening at the protocol and application level. Aaron suggested a couple of good ones, but I didn’t see a reference to one of the best in my opinion for protocol analysis: tcpdump and Ethereal.
  • Didn’t read any mention of chunked encocoding and gzip for dynamic responses, but the capability can be a major performance improvement for HTTP 1.1 and dynamically generated responses. For example, TTFB (time to first byte) can be perceived as slowness versus the TTLB (time to last byte). Sending chunks versus buffering entire responses to get a content length can help with TTFB implications.

There is so much more that could be written, but that will have to do it for today’s entry. At some point I hope to take some of my own math models and simulations and plug them into dent. All in due time….

Tags: ,