the system from realistic points. For example, if 50% of a system's user base will be accessing the system via a 56K modem connection and the other half over a T1, then the load injectors (computers that simulate real users) should either inject load over the same mix of connections (ideal) or simulate the network latency of such connections, following the same user profile. It is always helpful to have a statement of the likely peak number of users that might be expected to use the system at peak times. If there can also be a statement of what constitutes the maximum allowable 95 percentile response time, then an injector configuration could be used to test whether the proposed system met that specification. Questions to ask Performance specifications should ask the following questions, at a minimum: In detail, what is the performance test scope? What subsystems, interfaces, components, etc. are in and out of scope for this test? For the user interfaces (UIs) involved, how many concurrent users are expected for each (specify peak vs. nominal)? What does the target system (hardware) look like (specify all server and network appliance configurations)? What is the Application Workload Mix of each system component? (for example: 20% log-in, 40% search, 30% item select, 10% checkout). What is the System Workload Mix? [Multiple workloads may be simulated in a single performance test] (for example: 30% Workload A, 20% Workload B, 50% Workload C). What are the time requirements for any/all back-end batch processes (specify peak vs. nominal)? Prerequisites A stable build of the system which must resemble the production environment as closely as is possible. To ensure consistent results, the performance testing environment should be isolated from other environments, such as user acceptance testing (UAT) or development. As a best practice it is always advisable to have a separate performance testing environment resembling the production environment as much as possible. Test conditions In performance testing, it is often crucial for the test conditions to be similar to the expected actual use. However, in practice this is hard to arrange and not wholly possible, since production systems are subjected to unpredictable workloads. Test workloads may mimic occurrences in the production environment as far as possible, but only in the simplest systems can one exactly replicate this workload variability. Loosely-coupled architectural implementations (e.g.: SOA) have created additional complexities with performance testing. To truly replicate production-like states,