Test environment versus production environment
After a Web site goes live, using it as a test environment is very dangerous. Therefore, common practice is to keep a separate test environment. The best possible scenario is when the test environment and production environment are identical. However, due to cost and maintenance considerations, that is rarely the case; the test environment is usually both smaller and simpler.
In most cases, we use the test environment both to create benchmarks and to run any further tests. We then map the results onto the production environment. The following information about both test and production environments is useful for establishing this mapping:
| Resources versus capacity |
CPU, memory, and hard drive characteristics are key for the capacity of a system. Doubling CPU or memory, however, does not yield twice the capacity. To get an accurate mapping, we must carefully monitor the test environment resource usage during test runs. Generally speaking, if you decide to make the test environment, say, a fifth the size of the production environment, then the components should be scaled to a fifth the size too. Memory may need to be the same as in the production environment. For example, a test database server would need to have the same memory as production because we will be testing with a full size database. The same applies to application servers and the JVM size.
|
| Capacity, workload, and response time |
The number of concurrent users and the response time are two inseparable measurements. Higher capacity can handle more concurrent users. More concurrent users mean longer response times. Different Web applications will have different relationships between capacity, workload, and response time. We should consider this relationship when mapping the benchmarking results from the test environment to the production environment.