Interpreting Stream Errors

Streaming errors can occur when something has not been configured properly. For example, the simulator could attempt to do one of the following:

• Stream using HTTP when the HTTP Server Control Protocol plug-in has been not been enabled.

• Connect to a stream to which the user does not have access.

• Stream a file that does not exist.

To track down errors, check all the monitors. For example, if you are receiving many client connection errors, but the CPU usage on the server and client computers are running low, the problem is probably caused by the configuration.

If the client CPU is running high, errors will show up that have nothing to do with server and network performance. Cut down on the number of clients and profiles and then check the client CPU again. You might notice that Windows Media 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 files, closing files, and seeking.

Windows Media Performance Monitor gives you the most detailed picture of the server during a load test. With it you can view the amount of processor time used, number of Players connected for different protocols, and more. 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 could be to blame. If streaming errors are occurring, check bandwidth usage to see if it is running up against the limit of your network.

The Monitor tab also provides general information about your CPU usage, clients connected, and current allocated bandwidth. Select your server in the console tree, and then click the Monitor tab to view these statistics.

Studying the Test Results

When the load test is complete, review the test logs to identify problems or trends. The Coho Winery Webmaster cross-checked the server and load simulator logs as a means of pinpointing problems. Client logging was not enabled.

For example, the performance log noted a high processor time and late reads due to a large number of concurrent connections. Nothing unusual occurred on the server at that time, so she suspected the network or a configuration problem.

Next, she checked the Windows Media Load Simulator log for clients that reported a high number of failures. If a client reported failure to open, the server configuration was OK, and the server was not under stress, then she determined a slow network or a stressed client computer could be the problem.

Running Windows Media Load Simulator and reviewing test logs provides you with the information you need to correct configuration errors and set limits. You can set limits for the entire server or individual publishing points. To set limits, select the server or publishing point node from the console tree and click the Properties tab. Click Limits, and then set the limits appropriate for your situation.

Setting Limits

When deciding what limits to set, remember that it requires less bandwidth to stream a few high-bit-rate streams than it does to stream many low-bit-rate streams, even though the total bit rate is the same. This is because each connection requires a certain amount of bandwidth for protocol overhead. Many streams also require more processing power and reads from the hard drive. This is also true of short files and long files. As you saw with the simulation, short files require more opening and closing of sessions and seeking, which require more bandwidth and CPU time than long files.

If your computer and network are slow, try limiting the number of Player connections or the connection rate. Coho Winery, for example, limited concurrent connections to 40 as a result of testing. If you need to preserve network bandwidth, limit aggregate Player bandwidth. Coho Winery limited this to 70 percent of the total available bandwidth. Limiting connection acknowledgement can be useful if the server is overpowered by many authentication requests.

In this chapter the Coho Winery completed the testing of their streaming media site, adjusted the server configuration as necessary, and set limits to ensure optimal performance from their server. At this point, their system is ready to go live.

Monitoring server performance and making adjustments are an ongoing part of any streaming infrastructure as usage patterns change, content is updated or added, software is upgraded, and hardware and network configurations are changed.

In the next part we’ll take the task of implementing a basic streaming media site and build upon it as we deploy Windows Media at an online movie company that provides live broadcasts of entertainment news while offering on-demand streams and downloadable content.