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 slower?" 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. 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.
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:
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.