Web performance in seven steps; how performance problems manifest themselves

Last week I blogged about the increasing load at web shops and the increasing challenges for developers and operators. The question to be answered was stated as: how can we prevent performance and availability problems; how can we assure that a web site is always quick and available? In this blog I’ll describe some of the forms in which I found performance difficulties to present themselves.
Frustrations and loss of revenue
When internal applications are slow, this is frustrating for the users. They cannot do their job efficiently anymore and will become de-motivated. Call center agents have to apologize continuously to the customer on the other end of the line for their slow systems. The customer in turn will become frustrated by having to wait so long. When external applications are slow, this will have direct consequences for the revenue of the company. For instance, if I want to buy a book or insure my car, I compare products online and choose a shop. If I have to wait when I am on such a site, I simply browse to the competitor to buy there. Since I will not be the only one behaving like that, this has its effect on the revenue.
Disruption of regular software development
Slowness problems most of the time manifest themselves unexpectedly, such as after the introduction of a new application or new release. A cause of this is that the non-functional aspects of the software usually get attention too late and too little in the development cycle. The difficulties which turn up in production put a high pressure on both the operators as well as the developers to solve the usually difficult to find problems, to troubleshoot. This will have its disruptive effect on the regular development of new releases: the development team is only busy firefighting.
Extra hardware: cheap solution?
The solution to the slowness is regularly sought in putting in more hardware: load balancing over more web servers or modern fashioned: run the app in an elastic cloud. However, if the bottleneck turns out not to be located in the web tier but somewhere else, this investment in more web servers will turn out to be just wasted money. Moreover, yearly returning licensing and operational costs are more than once under-estimated. So, in case extra hardware is a solution at all, it may be an easy solution, however, it is certainly not always a cheap solution.
Next time, I’ll deal with the first step to ensure a speedy web application: define performance requirements.