Web Performance Matters

Recently I've been doing a lot Web design and development work, using the Squarespace platform, a "A fully hosted, completely managed environment for creating and maintaining a website, blog or portfolio." I like Squarespace because it is xhtml/CSS based and lets me focus on a site's content and appearance. I get great performance and never have to deal with installing and managing any Web server software. Normally ...

Click to read more ...

Earlier posts about Acceptable Response Times have discussed how a Web site or application's responsiveness can Delight, Satisfy, or Frustrate customers.

Availability, on the other hand, is a measure of a system's stability. It is not a performance metric, it is a software (or hardware) quality metric.

So, technically speaking, performance and availability are orthogonal issues. Practically speaking, however, availability and responsiveness are interconnected concepts.

Click to read more ...

I was going to write about performance and availability today, but this was not the post I had in mind. Technorati sidetracked me. So I'm going to write about Usability instead. Because Technorati provides a good counter-example -- how not to build a usable Web application that satisfies and retains customers.

In Web Usability: A Simple Framework, I described a way to think about Web site or Web application usability.

In a second post, The Dimensions of Usability, I presented the graphic shown here, and discussed the four dimensions in a bit more detail.

These four dimensions are not alternative functional goals, to be weighed against one another and prioritized. Web application effectiveness is a four-step challenge:

Click to read more ...

Coding Horror

The best products are designed with Human Factors in mind. That's why I often write about Web design and usability in my Web Performance Matters blog.

Jeff Atwood recently published Thirteen Blog Clichés, a post summarizing his "opinions about what makes blogs work well, and what makes blogs sometimes not work so well." These are presented as a list of common mistakes to avoid (or anti-patterns). If you have a blog, or are designing one, you've probably read similar articles before. Even so, Jeff's checklist is worth a look. All such lists tend to contain a core set of common guidelines to follow and/or pitfalls to avoid, but some of Jeff's opinions step outside the conventional wisdom.

Because I maintain two blogs -- Web Performance Matters and UpRight Matters -- I decided to rate both blogs against Jeff's criteria. Here are edited versions of his recommendations, and my responses. To read Jeff's full discussions of each guideline, see the original. And for the full story, see the many responses posted by Jeff's readers in the comments section of his blog.

Click to read more ...

If I had a hammer
I'd hammer in the morning
I'd hammer in the evening
All over this land
I'd hammer out danger
I'd hammer out a warning
I'd hammer out love between my brothers and my sisters
All over this land

--Pete Seeger and Lee Hays, 1949 [Wikipedia]

In May 2007, after I wrote about Controlling What You Can't Measure, I had a conversation with Ben Simo (see the comments) about metrics and tools ...

Click to read more ...

My recent post, Asynchronous Architectures [4], summarized a presentation by Werner Vogels at the 2007 QCON conference in London.

A subsequent post by Kent Langley in his new ProductionScale blog -- entitled Getting Rid of the Relational Database -- supports the arguments advanced by Vogels.

Click to read more ...

Peter Drucker is often called "the father of modern management". Many books and Web sites are devoted to his insights, some of which I have written about previously.

This post highlights his incisive observation about the difference between effectiveness and efficiency. I have always found it to be especially memorable, and quoted it (twice) when discussing priorities and choices in my book about software performance. Unfortunately I got the source wrong, but thanks to Google I can now correct my mistake.

It appeared in Managing for Business Effectiveness, an article in the May/June 1963 edition of Harvard Business Review ("HBR"). You can also find it in a February 2006 HBR article -- What Executives Should Remember -- a collection of excerpts drawn from HBR articles by Drucker published between 1963 and 2004.

Click to read more ...

This is the fourth in a series of posts presenting arguments for asynchronous architectures as the optimal way to build high-performance, scalable systems for a distributed environment.

In a QCon conference presentation on Availability and Consistency or how the CAP theorem ruins it all, Werner Vogels, Amazon CTO, examines the tension between availability & consistency in large-scale distributed systems, and presents a model for reasoning about the trade-offs between different solutions. I recommend you find time to watch the entire 52-minute video.

Click to read more ...

This post is the third in a series presenting arguments for asynchronous architectures as the optimal way to build high-performance, scalable systems for a distributed environment.

The first reviewed the case for asynchronous communication among interdependent components or services, and Bell's Law of Waiting. The second highlighted The Fallacies of Distributed Computing, and discussed the importance of reflecting the business process in distributed systems design.

This post reviews The Challenges of Latency, an article about how asynchronous architectures can improve the quality of Web applications, published on the InfoQueue site by eBay architect Dan Pritchett in May 2007. Dan's article is especially relevant today, given the high level of interest in adopting Web services and SOA approaches.

Click to read more ...

This post is the second in a series presenting arguments for asynchronous architectures as the optimal way to build high-performance, scalable systems for a distributed environment. The first post reviewed the general case for asynchronous communication among interdependent components or services, and highlighted Bell's Law of Waiting.

The Fallacies of Distributed Computing highlight crucial differences between centralized and distributed computing. Network components introduce potential problems that a centralized solution does not have to consider.

In this post I discuss how the design of distributed systems should draw on that of manual business systems. Of course, distributed computing can shorten the timescales of some business operations enormously. But drawing analogies with the way manual systems work is an observation that will help us to design efficient and scalable distributed systems.

Click to read more ...