Web Performance Matters

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

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

Latency, Bandwidth, and Station Wagons focused primarily on the limitations of network bandwidth, and the time required to transmit massive data volumes. While that is an interesting topic, and one that produces some surprising results (like the fact that FedEx is still faster than the Internet), it is not particularly relevant to the subject of Web performance, which depends on the time required to transmit many small files.

My post highlighted It's Still The Latency, Stupid, by William (Bill) Dougherty in edgeblog. Bill's title pays homage to a famous 1996 article by Stuart Cheshire about bandwidth and latency in ISP links, It's the Latency Stupid.

Over a decade later, Bill points out, Cheshire's writings are still relevant: One concept that continues to elude many IT managers is the impact of latency on network design ... Latency, not bandwidth, is often the key to network speed, or lack thereof. This is especially true when it comes to the download speeds (or response times) of Web pages and Web-based applications. In this post I explain why, providing some supporting references and examples to support my argument.

Click to read more ...

Do you subscribe to email newsletters? If you're like me, you get lots of them. New ones appear in my inbox every morning. They pile up, demanding to be read. In fact, they seem to breed like rabbits, producing new offspring -- when did I express an interest in Enterprise VOIP Security Architecture issues? Sometimes in a housekeeping splurge I delete a few dozen at once, suffering a momentary twinge of anxiety at having perhaps missed something important. So usually I skim them before hitting the delete button.

TechTarget's Search Software Quality service seems to be especially prolific, but is also a regular source of interesting references -- like TheServerSide.com, the subject of a recent note. According to the site's home page:

Java Performance Management for Large-Scale Systems

There are many classes of enterprise applications that have stringent performance and scalability requirements. TheServerSide.com has assembled a collection of resources to help you better design, develop, test and manage high performance, large-scale systems - learn new and innovative approaches for performance tuning, memory management, concurrent programming, JVM clustering and more.

Click to read more ...

Clustering and distributing Java applications has never been easier than it is today. As a result, writing good distributed performance tests and tuning those applications is increasingly important. Performance tuning and testing of distributed and/or clustered applications is an important skill and many who do it can use a little help.

That paragraph introduces a new series of four posts about how to approach testing for distributed Java applications by Steve Harris of Terracotta, who blogs as DSO Guy. Steve frames his guidelines as anti-patterns -- in other words, pitfalls or "commonly-reinvented bad solutions to problems" to be avoided [see Wikipedia].

Click to read more ...

Where performance is concerned, you should never underestimate the importance of the customer's perception. Usability specialists know this, because they focus on quality metrics that cannot be measured except by asking (or observing) customers. But technical professionals, who focus on more concrete metrics, tend to ignore issues of user perception.

Yet no matter how much time we spend systematically and objectively designing, measuring, and tuning our products to make sure that they really do run fast enough, in the end customer satisfaction is always a very subjective matter.

Click to read more ...

Performance Management (SLM) Challenges for Web 2.0, Ajax, and Rich Internet Applications (RIA's)

Last week, TechTarget published an article by Patrick Lightbody about the performance of Web 2.0 applications. The article's technical core -- which I review below -- is a useful checklist of ten recommendations for developing and testing Web 2.0 applications with performance in mind.

For the full article, see Ten ways to improve testing, performance of Web 2.0 applications.

Because I believe in systematic performance engineering, I am always pleased when writers advocate proactive approaches to application performance. It's the only rational way to ensure acceptable performance in production applications. So it's too bad that Patrick feels the need to justify his good advice by surrounding it with an introduction and conclusion that suffers from all the worst features of Web 2.0 coverage. A few half-truths are buried in an amalgam of excessive hype, false claims, meaningless analysis, and an optimism that underestimates the real technical challenges.

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

The first post in this series discussed Moore's Law and Wirth's Law. It reviewed how, at an industry level, ever faster processors have been neutralized by ever-growing software. Here I discuss how to manage the balance between hardware and software at the enterprise or application level with a systematic approach to performance tuning.

Performance is all about supply and demand. Performance problems are the visible evidence of a mismatch between hardware supply and software demand -- between the amount of work the software wants to do and the hardware computing resources (processor, memory, storage, or network capacity) available to handle that work. Such mismatches can be caused by resource utilization or contention:

Click to read more ...

Many developers seem to assume that Moore's Law, with its prosect of endless capacity growth, will rescue them from any performance problem. But this vision of unlimited scalability will always be just that -- a vision, not a reality.

If you're reading anything on this site, I think its safe to assume that you're familiar with Moore's Law. Anyone old enough to have owned a few computers has experienced Moore's Law at work in the progressive increases in the processing power of each new generation of hardware.

But while Moore's law is almost a household term, how many people have even heard of Wirth's Law? Yet it describes a parallel phenomenon, and one that arguably has affected our lives every bit as much -- the systematic slowing of software performance. In fact, as Wirth observed, in the race between hardware efficiency and software bloat, the software developers are "winning".

Click to read more ...