Web Performance Matters

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

In Five Scalability Principles, I reviewed an article published by MySQL about the five performance principles that apply to all application scaling efforts. When discussing the first principle -- Don't think synchronously -- I stated that Decoupled processes and multi-transaction workflows are the optimal starting point for the design of high-performance (distributed) systems.

That's a quote from High-Performance Client/Server, from a section on Abandoning the Single Synchronous Transaction Paradigm, in Chapter 15, Architecture for High Performance. My 1998 book is out of print now, and contains some outdated examples and references. But most of the discussions of performance principles are timeless, and you can pick up a used copy for about $3.00 at Amazon.

So I am planning some more posts built around excerpts from the manuscript. I'll be updating and generalizing the terminology as necessary for today's environments, and adding some guidelines in my Performance Wisdom series.

Click to read more ...

The 12 Days of Scale-Out is a section of the MySQL site. It consists of a series of twelve articles, eleven of which are case studies describing large-scale MySQL implementations. But Day Six is a bit different -- it spells out five fundamental performance principles that apply to all application scaling efforts.

This subject is vitally important to MySQL, whose server replication and high availability features ... allow high-traffic sites to horizontally 'Scale-Out' their applications, using multiple commodity machines to form one logical database -- as opposed to 'Scaling Up', starting over with more expensive and complex hardware and database technology.

I know from first-hand experience that these claims are valid. At Keynote, my team used MySQL as the foundation for the Performance Scoreboard. In this data mart application, MySQL supports supports the continuous insertion of new measurements at the rate of several million per day, plus hourly aggregation into summary tables, plus the queries needed to support continually updated dashboard displays for every customer, plus any ad hoc queries generated by customers doing diagnostic investigations.

Click to read more ...

Buying test tools is sometimes just like buying a new car: the salesman tells you that the car is reliable and has a great warranty; then the finance person warns of everything that could go wrong that isn't covered in the warranty and trys to sell you an extended warranty and maintenance contract.

Ben Simo, the author of the first paragraph, writes the blog Quality Frog. He is a software tester and test automation developer. His blog contains his "ramblings about software testing" and links to useful resources. In his post Performance Testing Lessons Learned, Ben shares his experiences with load testing and load testing tools.

Click to read more ...

Recent posts have discussed some insightful statements about the importance of measurements by Lord Kelvin, Grace Hopper, Tom DeMarco, and Tom Gilb.

In the last of these, I concluded that Gilb's observation (Anything you need to quantify can be measured in some way that is superior to not measuring it at all) gets across the value of measurements without making any claims that are too far-reaching or contentious.

A follow-up comment and the ensuing conversation with Ben Simo -- author of Quality Frog, a blog about software testing and software quality -- reminded me of this post, which I'd been meaning to complete and publish for a while. I'll explain the reasons for the delay below.

Click to read more ...

Performance testing is the discipline concerned with determining and reporting the current performance of a software application under various parameters. But there comes a time after the tests are run when someone who's reviewing the results asks the deceptively simple question: So what, exactly, does all this mean? This point beyond performance testing is where the capabilities of the human brain come in handy.

With these words, Scott Barber introduced a series of articles on IBM's DeveloperWorks site about the human aspects of performance testing.

Click to read more ...

Posts on The Importance of Measurements and Controlling Software Projects have reviewed the origin of the saying that "you can't manage what you can't (or don't) measure". Today I look more closely at its meaning and validity -- how true is it?

One apparent contradiction is that this much quoted fact of management is also widely viewed as a fallacy -- or at least, as an over-exaggerated claim -- especially by people in the software engineering profession, which seems (in the person of Tom DeMarco) to have coined the saying in the first place. That contradiction was highlighted in a 2003 book by Robert L. Glass, Facts and Fallacies of Software Engineering [Amazon].

Click to read more ...

Previous posts in this series described the influence of Moore's Law and Wirth's Law on application performance, how to balance hardware capacity and software demand with a systematic approach to performance tuning, and the five fundamental elements of computer system performance.

This post is the second of a small group devoted to the importance of measurements. Kelvin's dictum ("if you cannot measure, then your knowledge is meagre and unsatisfactory"), and the popular saying, "you can't manage what you can't (or don't) measure," each advance the idea that measurements are indispensable.

But such a sweeping claim may not actually be true in every instance, so I am now highlighting some slightly more focused statements about the value of measurements.

Click to read more ...

Previous posts in this series described the influence of Moore's Law and Wirth's Law on application performance, how to balance hardware capacity and software demand with a systematic approach to performance tuning, and the five fundamental elements of computer system performance.

Today's post is the first of several that will review insights on the central importance of measurements. Previously I've described how I view measurements as the foundation of all performance management -- see, for example, The ABC's of Measurement Data and my review of Practical Service Level Management.

Today's quote by Lord Kelvin sums up my point of view. Unless you have measured something, your attempts at managing it, and maintaining or improving its performance, will be unscientific at best ...

Click to read more ...