Designing for Performance
Define performance requirements before development and debugging begins. To define a good performance requirement, you must identify project constraints, determine services that the application will perform, and specify the load on the application. You can then use this information to select appropriate metrics and determine specific performance goals.
Changing some aspects of a project to improve performance may not be an option. There may be constraints on the schedule or on the choice of development tools or technologies. For example, contractual obligations may require application deployment by a particular date. If the development team has Visual Basic expertise but no expertise in Visual C++, it is impractical to develop components using Visual C++. Hardware constraints might also be a factor, particularly for user workstations. Document all constraints because these factors are constant during performance tuning. If you cannot achieve satisfactory performance within these constraints, management or customer intervention is required.
Modify aspects of the project that are not constrained during the tuning process to determine if you can improve performance. For example, can you implement components in a different language? Can you use a different data access technology? Are transactions really needed? Can you add computers to the application topology? These questions can help identify ways to remove bottlenecks in the system.
Applications typically provide one or more features that correspond to use cases and usage scenarios. Usually each scenario can be described as a set of transactions. Even if transactions are not involved, a sequence of interactions with the user takes place for each scenario. Define the semantics of each performance-sensitive scenario (what the user does and what the application service does in response) precisely, including how the feature accesses databases and other system services. These definitions drive the tests that measure performance.
In addition to defining which features to measure, define how often they are used. Accurate estimates of the usage of various application services help create tests that closely mimic the expected usage of the system, improving the accuracy of performance test results.
Specifying the Load
A common way to measure the load on an application is to identify the number of clients that will use the application. A related measure is think time, which is the elapsed time between the receipt of a reply to one request and the submission of the next request. For example, if it takes about 60 seconds for a user to enter all the information required for a Web-based time-entry form, 60 seconds is the think time for the Time Entry scenario.
Consider load variance over time. For some applications, the load remains fairly constant, while for other applications the load may vary. For example, a payment processing application will have a heavier load during the week when payments are due. An insurance claims application will have a heavier load when a natural disaster, such as a hurricane or tornado, occurs. A help desk application will have a heavier load in the month following the release of a software upgrade. Information about how the load varies over time can be used to determine the peak and average system loads. You can base performance requirements on either or both of these measures.