- The Network
- The Servers
- The Load Generators
- Hardware and Test Planning
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Hardware and Test Planning
Many teams bring all of their hardware online and start testing. Invariably, they experience performance problems and spend lots of time trying to isolate the components or applications contributing to the bottleneck. A better approach calls for bringing hardware components into the test systematically to gauge the performance impact of each piece of equipment.
We recommend limiting the hardware involved in early phases of testing. The first step in the test might be a network performance test, as shown in Figure 9.7. If the tester sends a file from the HTTP server to the application server via FTP, does it take more or less time than sending it from the application server to a legacy system? This simple test validates the network across multiple points, and it can be very important if multiple network segments are engaged in your environment.3
)
Figure 9.7 Testing the networks with FTP
Next, bring an HTTP server and an application server on-line for testing. Initially, consider stubbing out calls to mid-tier and legacy databases, or use test script primitives (as discussed in Chapter 7) to test only HTTP and servlet function without exercising the back-end systems. (Figure 9.8 outlines a progressive performance test strategy using a typical test environment.)
)
Figure 9.8 One possible test ordering for a large test environment
Add these systems into the mix only when you're certain of the soundness of the HTTP server and application server configuration. After successfully testing and tuning a single HTTP server and application server with the back-end systems, add multiple HTTP servers and application servers to the cluster to test scalability. Next, increase the complexity of the test by turning on the firewalls and, later, the reverse proxy server. At this point, you might decide to exercise the SSL portions of the web application using test scripts.
This approach allows you to bring hardware into the test in a layered fashion. Key components come into the test, receive intense test scrutiny and tuning, and, as a result, stabilize. Of course, this technique requires planning. Plan the network topology carefully to support easy removal and addition of key components. In the long run, you benefit by understanding the performance impact of each piece of hardware used in the web site.