Collected thoughts about software and site performance ...
Web performance matters. Responsive sites can make the online experience effective, even enjoyable. A slow site can be unusable. This site is about online performance, how to achieve and maintain it, its impact on user experience, and ultimately on site effectiveness.
Home | Entries from July 1, 2007 - August 1, 2007, in reverse date order:
Latency, Bandwidth, and Response Times
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.
Java Performance Optimization
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.
Latency, Bandwidth, and Station Wagons
One concept that continues to elude many IT managers is the impact of latency on network design. 11 years ago, Stuart Cheshire wrote a detailed analysis of the difference between bandwidth and latency in ISP links [It's the Latency Stupid]. Over a decade later, his writings are still relevant. Latency, not bandwidth, is often the key to network speed, or lack thereof.
That's from It's Still The Latency, Stupid by William (Bill) Dougherty, writing in edgeblog on May 31, 2007. Bill follows that opening paragraph with a very readable explanation of the vital importance of latency (round-trip time) as a factor affecting performance in TCP networking. He uses what he calls the Sandbag Problem to illustrate his points:
Four Laws of Web Site Performance
Managing Response Time for Web Sites and Web Applications
Human beings don’t like to wait. We don’t like waiting in line at a store, we don’t like waiting for our food at a restaurant, and we definitely don’t like waiting for Web pages to load.
Those words open Web Page Response Time 101, an excellent article by Alberto Savoia. Although it was published in July 2001, it remains every bit as relevant and useful today. It does a really good job of explaining and summarizing two fundamental aspects of Web performance -- human behavior and site behavior.
Distributing Java Applications
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].
Acceptable Response Times
Response Time Standards for Web Sites and Web Applications
It feels like hardly a single day has passed in the past six years that someone hasn't asked me this questions: "What is the industry standard response time for a Web page?" And in the past six years, the answer hasn't changed, not even a little bit. So if the answer hasn't changed, why am I still getting asked the question on virtually a daily basis?
That is a quote from Acceptable application response times vs. industry standard, an article by Scott Barber published by TechTarget on March 13, 2007.
As I read Scott's article, I found myself in strong agreement with every point. By the end, I realized that Scott had echoed and summarised many previous posts of mine. So I have used Scott's words as a framework to collect together references to my previous articles on the subject of performance objectives -- what they should be, and how you should set them:
Performance is Always Subjective
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.

