Take It to the Limit

When civil engineers design a bridge, they try to determine the point at which demand and capacity intersect. Demand is composed of factors outside the physical structure of the bridge, such as the maximum number of vehicles that can be on it at one time and the number of vehicles that will cross it in a year. Capacity has to do with the known strength of bridge construction materials.

Server engineers face the same demands as bridge builders, although in a somewhat more virtual fashion. If a server supporting a mission-critical Windows NT application becomes processor bound and unresponsive during the busiest time of day, cars won’t fall into rivers, but the engineer who attested that the server would be able to handle the demand might feel like jumping.

Administrators face questions about capacity nearly every time they need to purchase or configure a server or an application, but they’re at a disadvantage compared with their counterparts in civil engineering. Determining a server’s capacity is an inexact science. You can use one of three methods to attempt it.

Rely on vendors’ recommendations. Hardware manufacturers and application software makers usually provide recommendations for the type of server hardware you should use and how you should configure the hardware and software. However, those estimates tend to be general and conservative.

Simulate the server’s actual use. If time and a suitable test environment are available, an application server’s engineering and construction phase can include a period during which that server is tested under "live fire" (i.e., actual use by users). Companies often use this method, however, for "proof of concept" rather than for a true capacity test (i.e., they don’t test the application server to the point of failure).

Use software to simulate a heavy workload. Simulation solves the other two options’ major shortcomings. On NT servers, you can perform workload simulation with a utility called Response Probe, which Microsoft provides in the Microsoft Windows NT Server 4.0 Resource Kit. (Response Probe is incompatible with Windows 2000.)

What Is Response Probe?
Server workloads can be difficult—even impossible—to duplicate because factors such as background network traffic and number of users logged on are hard to control. Response Probe’s strength is its controllability. Response Probe lets you design a reproducible, application-independent workload and use it to test the performance of a server’s hardware and software configuration without anyone having to use the server. The tool doesn’t manipulate the application running on the system; rather, it evaluates performance by generating unique threads that create a specific load on the server. In other words, Response Probe replaces the application in question. You run Response Probe instead of the system’s primary application but along with the system’s secondary applications.

Response Probe works by simulating real computer use. By real, I mean that the tool simulates a typical workload cycle—a variable think time followed by file access followed by computation. Response Probe assumes that many characteristics of real workloads follow a standard bell curve, or normal distribution, and designs the test workload accordingly. For example, the time that users spend thinking about what action to take varies from user to user and task to task, and the time spent finding a record in a file varies according to the location of the record on the hard disk relative to the read arm’s current position. Response Probe assumes that in a typical workload, these and other workload variables are distributed normally and so can be described by specifying a mean and a standard deviation. (For details about how to use a mean and standard deviation to specify a normal distribution, see Chapter 11 of the Microsoft Windows NT Workstation 4.0 Resource Guide at http://www.microsoft.com/technet/prodtechnol/ntwrkstn/reskit/03tools.asp?frame=true) Response Probe lets you specify means and standard deviations for several such workload characteristics, as you’ll see later.

To test your server’s performance, Response Probe relies on three closely linked text files that describe the simulated workload. These three files are

• a process script file (.scr), which creates each process in the test workload
• a thread definition file (.scp), which creates the threads that will run in the process
• a thread description file (.sct), which describes a thread process (You need a thread description file for each thread you define.)

Response Probe requires at least one of each of these files for every test it performs.

Using these files, Response Probe generates a precise activity level that’s identical each time you run the same script configuration. By varying the script parameters from test to test, you can first establish a baseline for performance, then use Response Probe to find the upper limits of a server’s capacity.

   Previous  [1]  2  3  4  Next