My Google Alerts today picked up a post from a former colleague of mine, commenting on another post from the Yahoo! Interface blog.

I had some problems following the stream in the Performance Matters post, so I thought I would this post to clear up my thoughts.

A technical note up front: Using a waterfall chart that only shows non-persistent connections gives a very skewed view on how a modern Web page page performs. Persistent connections and modern TCP/IP stacks with fast-retransmit algorithms and window-scaling have seend a trend away from network-related performance issues in the recent past.

After the dot-bomb crash, the overabundance of bandwidth (in the form of over-built fiber-optic networks) made backbone and end-to-end connectivity issues for business and most home broadband users almost completely disappear.

The wealth of bandwidth (ok, North America consumers arethe poor cousins compared to their European and Asian counterparts) removed the veil of “it’s the network” which had been the crutch of performance engineers for many years, and exposed the effects of poor design and badly designed infrastructure.

In many cases, poor page design could be overcome. However, issues with core infrastructure and application design were (and are) notoriously difficult to resolve without spending a lot of money and investing a large amount of time and manpower.

So, when these issues were combined with the shrinking budgets and constricted IT staffing in the post-boom era, application performance issues became (and still are) the root-cause of most Web performance issues.

In recent months, as the use of Internet telephony, rich-media streaming, file-sharing, RSS, and SOA products rise nearly exponentially, the bandwidth crunch is starting to re-appear. This is something I first speculated about in October 2005 [here].

In one area, I do agree with the Performance Matters post: the larger the page, the slower download. However, the ongoing debate is one that pits the “more smaller” crown against the “fewer larger” crowd. The “fewer larger” crowd appears to be losing, given the design of most modern Web pages.

The only other comment I can fairly make here is that the majority of the sources cited in the Performance Matters post are 5-6 years old. In that time, I have learned a lot about Web performance, and that the post is more relevant to to the state of the Internet at that time, and not now.

Tags: broadband, designed infrastructure, Google, Internet telephony, IP telephony, North America, over-built fiber-optic networks, SOA, TCP/IP, Web page page, Web Performance, Yahoo!

My musical tastes run the gamut. The sublime includes Gregorian Chants, Baroque music, and ethereal soaring symphonies.

But I was raised in a small town in the BC interior. Metallica is in my blood.

Oh, you may try and deny your Metallica-ness, but you know it’s there. It’s the one that makes you want to drive fast on the 280 between San Mateo and Sand Hill Road. The one that sees you doing the rocker salute and hair-wave when the kids are out. The one that makes do those 10 extra reps at the gym.

I thought Motorhead and AC/DC could soothe the beast.

No hope.

Out comes Kill ‘Em All.

Now, all I need is a very fast car.

Technorati Tags: Metallica, Kill ‘em all, Motorhead, AC/DC

Tags: ARIN, EAD, HTTP, IE, IM, it, Om, One, pr, run, SOA, Technorati

This article by James Governor highlights the issues with the use SOAP for Web services.

As a hack and slash programmer, SOAP is daunting, and very difficult to implement and use; in most cases, I would rather go straight to a database.

Make Web services EASY! That’s all. Simple calls to known APIs in programming languages used by Web programmers. That’s all we want. We will use a Web service if is easy to plug in to what we already have.

Tags: API, data, database, EAD, HTML, HTTP, IM, Issues, it, LAN, Om, pr, SOA, web