Running the Simulation

At this point, the Fabrikam technicians start Windows Media Load Simulator and watch the monitors. The following sections describe what they watch and how the information can be interpreted:

Load Simulation Status

This tab on Windows Media Load Simulator shows when the test begins and ends, and lists streaming errors that occur during the simulation when a setting has been configured improperly. For example, an error is raised when Windows Media Load Simulator attempts to stream using HTTP when the HTTP Server Control Protocol plug-in on the server has been disabled, attempts to connect to a stream to which the user does not have access, or attempts to stream a file that does not exist.

Barring configuration errors, streaming errors can occur if the server, network, or client computer cannot process a request or handle a stream. To track down errors, check the other monitors. For example, if you are receiving many client connection errors, but the CPU usage on the server and client computers are running low, there is a good chance the problem is caused by a configuration error and not server load.

Client Performance

If the client CPU usage is running in the high percentages, errors will show up that have nothing to do with server and network performance. Cut down on the number of simulator clients and profiles. You might notice that Load Simulator requires more of the client computer’s CPU and memory when it runs many tasks. You could try cutting down on the number of tasks if you want to increase the client count. For example, the client computer can more easily handle 50 long-play clients than the same number of clients opening, closing, and seeking.

Server Performance Monitors

These indicators provide the most detailed picture of a server during a test run. You can view % Processor Time, number of players connected for different protocols, and many more counters. As the simulation runs, watch for problems such as an increase in Late Reads, Memory, and % Processor Time.

If client errors occur in conjunction with an increase in these counters, either a slow CPU or slow hard drives might be a problem. If streaming errors are occurring, you can also check the bandwidth usage to see if it is running up against the limits of the network.

Group Details or Monitor Tab

For a high-level picture of the simulation, check the indicators in Group details or the Monitor tab for each server. These screens will show you general information, such as CPU usage, total number of clients connected, and the current allocated bandwidth.

With a server farm like the one Fabrikam is using, CPU usage will be very low, late reads probably nonexistent, and errors very rare when running simulation tests. It is more likely that problems will originate on the network or the client computer. If the servers are functioning and configured properly, the server farm should be able to handle thousands of client connections, depending on the bit rates being streamed and number of different streams. As the Fabrikam technicians increase the number of clients, they will probably begin to see network errors, such as errors reading from the network and failed network connections. The 1000-Mbps network can handle far less traffic than the server, and the one client computer can handle even less.

If you need to stress test a server, you can add more client computers and a faster network. However, doing so would not give a realistic picture of the servers in production. You can try several different client scenarios, and then run a simulation overnight. In the morning, you can check memory usage and glance through the logs to note any unusual errors. Typically, the limiting factor for streaming on-demand content is hard drive input and output. The limiting factor for streaming live content is the CPU.