Most developers have had the unfortunate experience of building a slow application. Obviously, developers don't set out to create slow applications, and there probably isn't a user group asking, "Could you please make the application run very slowly for us?" Too often, bad performance isn't discovered until the application is finished and installed into a production environment. But why does this happen?
The simple truth is that it happens because not enough attention is given to performance matters during design and construction. This is not to say that performance should be the primary focus at all times—if you focus on performance too exclusively or too soon, it may negatively affect the design and code. On the other hand, if you wait too long, you may find yourself with upset users complaining about poor performance, and you'll be left wondering what went wrong.
You may have heard the axiom "Test soon, test often." This is a good principle to follow to help ensure that you are not surprised at the end of construction with a poorly performing application. The sooner you can detect a performance problem, the more likely it is that you'll get a chance to fix it before the application goes into production. Another apt saying is "Don't leave any broken windows." This means that when you detect a problem, you should fix it and not let it linger. Picture a building with a broken window that's not immediately fixed. If people are led to believe that having one broken window in the building is acceptable, they will eventually decide that it's all right to have many broken windows. Before long, the building will be in shambles, and all the tenants will have moved out. If you find obvious performance problems during early tests, fix them.
So how do you measure the performance of a web application? What's considered acceptable or too slow? The answers to these questions are strictly related to the nonfunctional requirements of the application.[1] There are tangible and quantitative measurements that can be taken to help determine whether the application is able to meet the minimum requirements set out in the nonfunctional requirements.
[1] The nonfunctional requirements are part of the analysis work that should be done for any nontrivial application. These requirements describe the broader issues of the application, such as availability, disaster recovery, package dependencies, hardware configuration, and, almost always, performance criteria.
The problem is that each application is different and therefore has different nonfunctional requirements. One application might need to have an average response time of 3.0 seconds and support 50 concurrent users, while another might have to support 500 simultaneous users. Performance testing is a little more nebulous than functional testing, where it's easy to see when the application fails to meet the design specifications.
According to Alberto Savoia, the Director of Software Research at Sun Microsystems's Laboratories, there are four behavioral laws that make web page performance critical to an organization's success:
This law states that web users are sticky, but not loyal. If they find a web site that serves their needs, they tend to continue to use that site. If the web site begins to respond slowly and cause the users to wait, they will move to another site that fulfills their same needs. The point is to strive to keep the performance of the application strong in order to keep the users coming back.
The Law of User Perspective
This law states that you should always measure the performance of your application from the user's point of view, not from your own. The point here is that, for example, while your environment may have a 100-MB network with an otherwise light load on it, the user may be using a modem with a much smaller bandwidth capability. Always keep in mind what the user's environment and network capabilities will be and test accordingly.
The Law of Responsibility
This law states that the users don't care what or who is at fault for poor web site performance; they will always blame the application. The problem might be their ISP or another nonapplication issue, but most users will not be able to isolate the problem to that level and instead will blame the application or site. You must be aware of all the factors that may impact the performance of your application.
The Law of Expectations
This law states that users' satisfaction is based on their expectations, which are set by their personal experiences with other, similar web sites. When measuring the performance of your application, don't rely just on arbitrary numbers to indicate what's slow or fast; compare your results with those of your competitors.
These simple, common-sense laws explain the human-behavior aspects of web site performance. In general, however, slow is slow and fast is fast, and generalizations can be made across applications and business domains. But before we discuss how to detect whether performance problems exist in an application, a distinction must be made between the types of performance testing that should be conducted.