Performance and scalability are not interchangeable terms, but it is understandable how people confuse the two. Performance problems typically do not become apparent until testers place an application under an increased load. However, performance and scalability are two distinct issues. Measuring the performance of an application when placed under ever increasing loads determines the scalability of that application. When performance begins to fall below the stated minimum performance requirements, you have reached the limit of the application's scalability. For more information, see Scalability.
Disregarding application performance will inevitably result in an application that performs poorly. The responsibility for application performance occurs both at design time and at run time.
At design time, developers must prevent the introduction of code that would otherwise hinder the application's performance. Developers can do their part by following accepted programming practices and taking advantage of the inherent performance enhancing capabilities of the programming language, targeted runtime environment, and data access methods. A common method for identifying troublesome code is to conduct routine code reviews. Performance obstacles encountered and corrected at this stage are typically cheaper and easier to repair. For more information, see Coding Techniques and Programming Practices.
At runtime, the application should undergo mandatory performance testing to identify application bottlenecks, such as contention for resources or slow-running code. Before an application undergoes extensive performance testing, it is crucial that all functional testing is complete. To put it simply, an application must work before it can work well. However, performance benchmark testing should begin as early as possible to identify problem areas at their introduction in the application. Compare successive benchmark tests to the initial application performance benchmark to determine progress or regression. Conduct such testing without unnecessary variations, such as changes in hardware, to allow accurate comparisons of successive tests. Once again, performance obstacles encountered early are cheaper and easier to surmount. For more information, see Testing for Performance.