Click Here to Install Silverlight*
United StatesChange|All Microsoft Sites
Windows Media Player 9 Series
|Windows Media Worldwide

Checking Server Performance with Windows Media Load Simulator

Microsoft Windows Media Load Simulator simulates the effect on a Windows Media server of having one to several hundred instances of Microsoft Windows Media Player streaming content. This article describes how to use Windows Media Load Simulator for testing a new Windows Media server system and monitoring performance after the server goes online. You will find out how to set up the tests and how to use the results to improve your system.


Bill Birney
Microsoft Corporation
April 2008

Applies to:
   Microsoft® Windows Media® Load Simulator 9 Series
   Microsoft® Windows Media® Services 9 Series or later


The first test of a Microsoft Windows Media Services installation is to connect a client to the Windows Media server and see if the client streams content. If it does, you can place the server online and feel reasonably confident that the system will handle at least a minimum client load. At some point, however, it is useful to see how the server handles a real-world client load, preferably not by using real clients.

Windows Media Load Simulator is a program that simulates the load placed on a Windows Media server from one or more instances of Microsoft Windows Media Player. This article introduces Windows Media Load Simulator and describes how to use the program to test and monitor the performance of your Windows Media servers.

The article contains the following topics:

Introducing Windows Media Load Simulator
Using Windows Media Load Simulator
For More Information

Windows Media Load Simulator can be downloaded from the Microsoft Web site. For complete details about configuring Windows Media Load Simulator and an explanation of all available features, refer to Windows Media Load Simulator Help.

Windows Media Services 9 Series is available as an optional, installable component in the Standard, Enterprise, and Datacenter editions of Windows Server 2003 (or x64-based versions of these operating systems). Windows Media Services 2008 is available as an optional, installable component in the 32-bit editions and 64-bit editions of the Windows Server 2008 operating system. For more information, see Decide which version of Windows Server is right for you. For complete details about installing, configuring, and Maintaining Windows Media Services, refer to Windows Media Services Help.

Introducing Windows Media Load Simulator

Simply knowing that your Windows Media server installation is capable of delivering content may not be enough to make you feel confident about your system. Before you expose your server setup to the public, you may want to know how your server or servers will handle the load. How will the servers and the network handle a burst of 500 connections in a matter of seconds, for example? How will your disk array handle 800 continuous on-demand streams? How will your servers' CPUs handle thousands of seek and authentication requests and hundreds of multiple-bit-rate streams?

You can run Windows Media Load Simulator on one or more client computers to simulate a large number of client connections. You can also configure the program to simulate a number of client behaviors, including playing content continuously, streaming multiple-bit-rate content, seeking on-demand content, and connecting by using authentication. You can test a server's upper limits by using Windows Media Load Simulator to load the server with more than 1,000 test clients or to monitor a server that is online. This section describes how Windows Media Load Simulator works and the system requirements.

How Windows Media Load Simulator Works

As the program runs, performance counters on the Windows Media Load Simulator interface give you real-time information about the number and type of clients connecting, the amount of data received, and connection errors. More real-time information is available on the Monitor tab of the Windows Media Services snap-in for Microsoft Management Console (MMC) or Windows Media Services Administrator for the Web. Counters on the tab display real-time client connection status. You can click the View Performance Monitor button on the tab to monitor the Windows Media performance counters. These counters provide information about the Windows Media server, such as the number of active streams, the number of hard disk late reads per second, and the percentage of the server's CPU that is in use.

After ending a test, you can study the results of the following logs to understand how your server is handling the simulated load:
  • Load Simulator log. Contains information about the connecting clients, such as client connection status, playback status, and connection errors.
  • Server performance log. Contains performance information about the computer running Windows Media Services, providing snapshots of system status at configurable intervals. This log contains information, such as the number of hard disk late reads per second, refused authorizations, stream terminations, and server CPU usage.
  • Windows Media server log. Contains information about the content accessed on a Windows Media server, listing connection status information, the name of content being accessed, and the amount of data lost during transmission.

You can run Windows Media Load Simulator to test the configuration of your server and network before the server goes into production and to monitor the health of your system after it is online. If necessary, you can modify settings for an online Windows Media server by using either the Windows Media Services snap-in or Windows Media Services Administrator for the Web. If your server's hard disk, CPU, and network hardware are running smoothly, a user can connect to the server quickly and experience a good-quality, uninterrupted stream. Network conditions and client bandwidth are often out of your control, but by using Windows Media Load Simulator, you can be sure that you have done all that you can do on the server to test the quality of the connection and stream to the user.

System Requirements

The following software and hardware configuration is recommended for a client computer running Windows Media Load Simulator:
  • Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows® XP Professional. Windows Server 2008 is not supported.
  • Microsoft Internet Explorer 6.0 or later
  • 550 megahertz (MHz) processor
  • 512 megabytes (MB) RAM
  • 100 megabit per second (Mbps) Fast Ethernet network connection
  • 20 MB of free disk space for software and log file storage

Using Windows Media Load Simulator

Windows Media Load Simulator has two primary uses: as a peak usage or stress tester, and as an online monitor. The following list summarizes the two modes:
  • Peak and stress testing. You can test each server offline during expected peak load conditions, and then study the results. After you do this, increase the load incrementally and note changes in server performance and the quality of the streams as you approach the limit of the server's capability. You can use the results to set a limit for the number of client connections allowed by the server. You can use one of the Windows Media Services administrative interfaces to set the maximum number of clients, the maximum bandwidth usage, and the maximum file bit rate.
    Results typically indicate problems with the computer's CPU, random access memory (RAM), or hard disk or with network bandwidth. For example, a slow CPU results in high CPU usage for a comparatively low number of client connections and results in a high number of pending connections and streaming errors. The Late Send counter in the Windows Media server can also indicate a slow CPU. A slow hard disk drive results in a high number of late reads under stress. Late reads are not typically a problem when the server is hosting static data, such as still images or Web pages. But, when the server is hosting real-time digital media content, data must be available at the moment it is rendered.
  • Online monitoring. When the server is brought online, you can connect one or two clients to your server continuously to monitor the general health of the system. You can also create a simple program or script that automatically logs alerts or generates warning messages. You can, for example, create a simple script that sends you an e-mail message when Windows Media Load Simulator generates a streaming error.

Follow the procedure in this section to use Windows Media Load Simulator in both modes to help you determine and maintain the health of your servers. The procedure contains the following sections:

Determining a Client Profile

Before you run a test, determine the typical peak client count and typical client profile. The typical peak client count is the highest number of clients that will stream content concurrently on a regular basis. The client profile is based on the type of content you will be offering and the ways that clients will use the content. Client actions (such as seeking, opening. and closing streams) and authentication require additional server resources and should be included in a complete simulation test. Because you cannot determine the limits of your server until you actually put it online, you should set your expectations in the simulation test to be higher than what you feel is realistic. Consider the following items when you are determining the client count and profile:
  • Concurrent streams. What are the average and maximum numbers of clients that will be connected concurrently?
  • Mix of broadcast and on-demand content. What type of content will you be offering to users? How much of the content is broadcast, and how much is on-demand?
  • Behavior of users. How will users play the content? Do you expect users to play content all the way through, or browse through the content?
  • Multiple-bit-rate content. How much of the content is encoded for multiple bit rates?
  • Authentication. Will users need to provide a user name and password to gain access to content?

Creating Test Source Content

If you can, use the same Windows Media files for the test that you will stream when the server is online. If you haven't created any content yet or if your content will be live, create placeholder content that closely simulates the bit rate and length of the actual content. For example, if you plan to broadcast a live event by using multiple-bit-rate encoding, encode a live placeholder stream with the same settings. In addition, encode content that contains a similar amount of on-screen movement. For example, if you will be streaming a live music concert that features frequent use of hand-held cameras, fast cuts, and lighting effects, use a tape of a similar concert as your simulated live source. If your content consists of hundreds of 30-second news interviews, create two or three files that contain similar material, and then make multiple copies of the files. The test files should contain the same type and amount of on-screen movement and scene changes as the actual content because these aspects of the video directly affect bit rate.

User behavior is determined, in part, by the nature of the content. For example, if your site has many short clips, a user is likely to open and close many files and browse or seek to different parts of files. The user will be looking for pieces of information. A lot of seeking and browsing by users might show up as late reads and high CPU usage on a server that is overloaded. If the content is live, hard disk access will be negligible. However, you might experience errors that result from a slow CPU or low RAM and an increased late send rate. Whereas clients can access on-demand content at any time, the client load on a server during a broadcast of live content is often higher because access is concentrated in one time period.

Serving multiple-bit-rate content and authenticating users to play protected content also places an extra burden on a server. Windows Media Load Simulator has methods that you can use to stress test both of these features.

Setting Up for Peak Usage Testing

Peak usage and stress testing should be performed offline by using a closed local area network (LAN). Windows Media Load Simulator creates the same server and network load that you would experience when an equivalent number of real clients are connected to your server. If you run a stress test over an active network, the test might consume all available bandwidth and prevent real users from gaining access to servers. By running peak usage tests over a closed LAN, you avoid disruption to users on a network or Internet, and you can to increase the bit rate as much as necessary to test all servers and local network hardware completely. The following diagram shows a typical LAN layout.

Figure 1. Layout of closed LAN for stress testing image

Figure 1. Layout of closed LAN for stress testing

This layout assumes a typical test condition: a Windows Media server capable of 1,000 concurrent streams at a bandwidth of 28.8 kilobits per second (Kbps) connected to five computers running Windows Media Load Simulator, each capable of simulating 200 client connections. The layout should also include a remote encoder computer if you want to use a live stream to test the system and a remote storage device or server if the Windows Media server will access on-demand files from that source.

The computers running Windows Media Load Simulator must be capable of simulating a number of client connections smoothly. This number is dependent not only on the number of simulated clients, but also the bit rate of the content and the available bandwidth of the network. For example, 200 simulated clients connecting at 28.8 Kbps use 5.6 megabits per second (Mbps) of network bandwidth, which can easily be handled by a 100 Mbps Ethernet connection. However, if the content streams at 300 Kbps, the aggregate bit rate would be 60 Mbps, which would be near the limit of the network. In addition to making sure your network can handle the bit rate, you should also use System Monitor to check the CPU and memory usage of the client computers to make sure the usage is below 50 percent. An overloaded client computer can introduce streaming errors that will affect the test results.

Very fast servers are capable of much higher stream counts. For example, a server with four processors and 1 gigabyte (GB) of RAM can potentially handle thousands of concurrent streams. To test a computer with this setup, you should add more simulated client connections or use faster client computers. The rule of thumb is to use three client computers for every one Windows Media server, if you want to maximize the capacity of the server. The 3:1 rule applies if the client computers have the same specifications as the server. If you are using client computers with slower processors, you will need to use more client computers. For example, if your client computers have the same specifications as your server computer and are connected to a fast network, you will require about three client computers running Windows Media Load Simulator to maximize the capacity of one server. In general, however, you will use Windows Media Load Simulator to test normal loads and to make sure your network and server are configured properly.

You can help to add scalability and reliability to your streaming media system by using Network Load Balancing clusters in Windows Server 2003 to balance server load. A load-balanced system is a cluster of servers that appears as one server to a client, effectively creating one server out of several. To envision this scenario, replace the single server in the previous diagram with a load-balanced server cluster. Run Windows Media Load Simulator tests against the whole cluster as well as against individual servers.

You can also install the Windows Server 2003 Scalable Networking Pack to free up CPU cycles for application-related tasks, such as supporting more client connections or increasing network throughput. (Scalable networking features are automatically included in Windows Server 2008.)

Configuring Windows Media Load Simulator

To configure Windows Media Load Simulator, specify the server to be tested, the source of the content to stream, and the client configuration. This section provides an overview of how to configure Windows Media Load Simulator; for complete details, see Windows Media Load Simulator Help.
  1. Enable the Windows Media server for load testing.
    To run Windows Media Load Simulator against a particular Windows Media server, you must copy a file named WMLoad.asf to the Windows Media root directory of the server, which is by default %systemdrive%\Wmpub\Wmroot. This file provides a mechanism that helps to protect your computer from unauthorized load-simulation tests. After you finish running load simulation tests, simply remove the file to prevent malicious users from running load tests against your server. Without this protection mechanism, a user on the Internet could, for example, simulate thousands of client connections to your server, which could prevent others from connecting to the stream and potentially overload your system. If you want to use Windows Media Load Simulator for online monitoring, keep the file in the root directory and restrict access to it by using publishing point security.
    To create the file, use any small file that has an .asf file name extension and rename it WMLoad.asf. Also, ensure that Allow new unicast connections is enabled for the Default publishing point in Windows Media Services.
  2. Specify a Windows Media server to test.
    In either the Configuration Wizard or the Load Test Configuration (Advanced) dialog box, type the static IP address or the fully qualified domain name (FQDN) of the Windows Media server or server cluster that you want to test.
  3. Specify source content.
    Add source content to Stream list. The list can include files or live streams, and you can specify whether Windows Media Load Simulator plays these items sequentially or randomly.
    You must also specify the streaming protocol (or combination of protocols) that will be used for the simulation, depending upon the version of Windows Media Player and the version of Windows Media Services that you are using. For more information, see What protocols can I use to stream to Windows Media Player? in the Windows Media Services FAQ.
  4. Create client profiles.
    A client profile defines a simulated client's playback behavior. Enter a number of clients for each profile to create an overall client profile. The total number of clients you enter should not exceed the capabilities of the computer running Windows Media Load Simulator. To simulate more clients, Windows Media Load Simulator can be run on multiple computers against a Windows Media server. For example, to determine whether a Windows Media server can handle 1,000 concurrent unicast clients, Windows Media Load Simulator can be run on five client computers, each configured to simulate 200 clients. The total number of clients connecting to your server from all simulation computers should equal the total number of concurrent connections you estimated for the typical peak client load. The following list describes each profile:
    • Play. Simulated clients play, pause, and restart streams.
    • Long play. Simulated clients play a stream continuously. If the content is a file, the client repeats playback when it reaches the end of the file.
    • Open/Close. Simulated clients open a stream but close before playing it.
    • Seek. Simulated clients seek forward and backward in a stream or, if the content is a server-side playlist, skip to different playlist items. If the content is a live stream or a file that is not indexed, the clients play without seeking.
    • Select. Simulated clients open a stream, and then play it at either a bit rate chosen at random (if the content is multiple-bit-rate content) or at the encoded bit rate (if the content is single-bit-rate content).
    • Random. Simulated clients browse content, play content for random lengths of time, seek through content, stop playback, pause playback, and sometimes close.
  5. Add authentication.
    Clients can be configured to use authentication to gain access to content on the server that is protected by using Windows Media publishing point security. To test authentication, you can set up access control on individual files or publishing points, and then have simulated clients attempt to access the content. You must configure both the Windows Media server and the computer running Windows Media Load Simulator for the authentication test. If you enable WMS Digest Authentication on the server, you will need to configure Windows Media Load Simulator to use the appropriate user names and passwords. For more information about publishing point security, see Windows Media Services Help.
  6. Enter test duration and enable logging.
    You can specify a duration for the test in hours, minutes, and seconds, or you can specify that Windows Media Load Simulator stop after a certain number of errors. You can also run the test for an indefinite period.
    You can configure Windows Media Load Simulator to create two logs, a Windows Media Load Simulator log file and a Server Performance log file, and specify locations for the files. In most cases, you should create both logs. By using the two logs and the Windows Media server log and then cross-referencing information, you can gain a good understanding of how the system functioned during a test run. Note that in order for the client computer to collect data from the Windows Media server the user who is logged on to the client computers must have administrator rights and permissions on the server.

Running the Test

After you have configured Windows Media Load Simulator to simulate a peak client load, start the simulation. This section describes the peak load test, how to analyze the results, and the stress test.

Running the Peak Load Test

Run the test for a minimum of two minutes. After starting the test, you should check the following things:
  • Watch the counters in the Load Simulation Statistics box. As the test runs, the number of Open Streams increases, as do the number of Clients Playing and Clients Seeking. As the simulated clients receive content, the Total Bandwidth (Kbps) and Packets Received counters increase as well. As the number of Open Streams approaches the total client count for the simulation computer, the counters should increase more slowly, and activity should level off after 30 seconds. If you do not notice the activity slowing, continue running the test.
  • Note the number of lost packets as the simulation reaches the peak client count. There should be no lost packets. If you do notice lost packets, check the Total Bandwidth (Kbps) counter to see how much bandwidth is being consumed by the streams to all the clients. If you are running the simulation on a closed LAN with optimal network conditions and the sum of the bandwidth counters on all client computers is well within the bandwidth capacities of the LAN, lost packets indicate that the server is overloaded.
  • Check the Test Errors counter and review any errors logged on the Load Simulation Status tab. The server logs an error when a client sends a command that the server cannot carry out. Not all errors indicate server problems, however. If a client cannot, for example, locate a file, the file name might have been entered incorrectly in Windows Media Load Simulator. If the security features are not set up properly, authentication errors might occur. If you are receiving many test errors, make sure the content is error-free and you have entered the correct paths and file names of the content.

You can also:
  • View system performance during the test. On the Monitor tab of the Windows Media Services snap-in, click View Performance Monitor. You can also right-click in the details pane in Windows Media Services to add counters and view performance results for remote computers. The counters in System Monitor display information that directly indicates the health of the system as more and more clients attempt to connect and play content. Of particular interest are the % Processor Time, Late Reads, Pending Connections, and Stream Errors counters. A % Processor Time count approaching 100 and an increasing Pending Connection count indicates that the CPU is too slow. You might also notice a rise in Stream Errors. Compare the Stream Error count to the number of Packets Lost and Test Errors indicated on the Windows Media Load Simulator interface. For more information about adding a remote server and performance counters, see System Monitor Help.
  • Check the Late Reads counter. You might also notice an increase in Stream Errors and lost packets in connection with Late Reads. Late Reads indicates a slow hard disk drive or array. If the Windows Media server is accessing content from another server, Late Reads can also indicate a slow network connection. You can add counters to System Monitor to better understand where a problem is occurring. For example, because a Windows Media server must stream content for real-time viewing, the amount of paging that a server must do greatly affects performance. You can add counters that check for excessive paging. A paging problem can usually be solved by adding more RAM. You should also watch the Current Late Send rate counter. Any value over zero indicates an overloaded CPU or network.
  • View client information in real time by using the Windows Media Services snap-in. On the Monitor tab, you can view the overall client connection status and bandwidth usage.

Analyzing the Peak Load Test

The three logs contain all the information gathered from the test. You can use the logs to pinpoint problems that can easily be missed while watching the counters in real time. You can also cross-reference information using log times. For example, suppose you want to understand why a particular test error occurred, such as "Failed to open." Using the time that the error occurred in the Windows Media Load Simulator log, you can try to locate an event in the server performance log. If the server performance log looks normal at that time, check the Windows Media server log. The server log shows the status of the clients connected at that time, including what content they attempted to play and any playback problems that occurred. In the server log, you may notice that the C-status code for the client connected at that time is 404. This is a standard HTTP/1.1 code that means that the server could not find the content. From this information, you can deduce that there was no server error at that time. The server performed correctly and attempted to locate content that didn't exist. The server log also lists the name of the file that could not be found.

By analyzing the results, you can also determine the reason for excessive packet loss, which could be the result of an overloaded CPU, and the reason for excessive stream terminations. Most server problems indicate that the server has an underpowered CPU, not enough RAM, or a slow hard disk drive. If the server does not appear to have any performance problems, excessive packet loss could be caused by an overloaded network or problems with the computer running Windows Media Load Simulator. For more details on analyzing the logs, see Windows Media Load Simulator Help.

Running the Stress Tests

If no problems occurred during the peak load test, you can run additional tests that incrementally add more clients. This type of testing is called stress testing and is used extensively by software testers to determine the maximum capabilities of hardware. Some problems may only occur during stress testing. You can use stress tests to find the upper limits of your server's capability. If some problems occur during a peak load test, you can add to the client load to see if the problems worsen. If they do, you may have to add more RAM, a faster hard disk drive, or a faster CPU. An alternative to these hardware upgrades is to restrict the number of unicast clients that can connect to the server by setting client limits on the Properties tab of the Windows Media Services snap-in. If the problems do not worsen with an increased client load, you can investigate the possibility of malfunctioning hardware, software conflicts, or encoding errors in the content.

To increase client load, click the Properties button in Windows Media Load Simulator and increase the number of clients in one or more client profiles. You can try adding 10 to 20 percent more clients, running another test, studying the logs, and then adding more clients. Continue adding clients and running tests until the server reaches its upper limit and the number of errors becomes excessive. Note the client load just before the upper limit is reached, and then consider this number to be the absolute limit for the computer.

To be thorough, run peak load tests that last up to several days. You should not see any change over time from the pattern you see after a few minutes of running a test. If you are using a load-balanced cluster of servers, run tests against each server as well as against the cluster as a whole.

Use the following guidelines as a starting point for tracking down potential problems when analyzing the logs and counters.

Load Simulation Statistics

Packets Lost
Any amount greater than zero when testing over a closed LAN indicates an underpowered server that may have a slow CPU, not enough RAM, or a slow hard disk drive.
Test Errors
Any value greater than zero could indicate an underpowered server or a content error, such as the file being accessed doesn't exist, a live source is not streaming, or a stream contains encoding errors.

Load Simulator log

Log fieldIndication
Error Text
Any error could indicate an underpowered server or a content error, such as the file being accessed doesn't exist, a live source is not streaming, or a stream contains encoding errors.

Windows Media Performance Monitor and server performance log

Counter/Log fieldIndication
% Processor Time
A continuous count greater than 50 indicates an underpowered CPU for the load being tested.
Late Reads
A server under typical load conditions should show no late reads. Late reads indicate a hard disk drive that is too slow for the load.
Late Sends
A server should show no late sends.
Stream Errors
When a server's CPU cannot keep up with the demand for data, it discards packets, which causes stream errors.

Windows Media server log

Log fieldIndication
Any amount greater than zero when testing over a closed LAN indicates an underpowered server that may have a slow CPU, not enough RAM, or a slow hard disk drive.
This field displays the percentage of packets that were received by a client. Should be 100.
This field displays a standard HTTP/1.1 code number that describes client status. For example, 404 indicates that a requested file or stream could not be found.

Setting Up for Online Monitoring

After you have developed a stable server configuration, you can move the system into production and continue to use Windows Media Load Simulator as an online client monitor. You can configure a computer running Windows Media Load Simulator to connect to the server through the Internet or from a remote point on a network, just as a client computer would. You can also continue to monitor the system by connecting the computer directly to the output of the Windows Media server or server cluster. By comparing readings from the two computers running Windows Media Load Simulator, you can determine if a problem is caused by the network or the servers. The following diagram shows the online client monitor setup.

Figure 2. An online client monitor setup image

Figure 2. An online client monitor setup

The reason for online client monitoring is to make sure the server is working properly and online. The alternative to running Windows Media Load Simulator to monitor an online system is to stream content to Windows Media Player on a continuous basis. You can, for example, create a simple Web page that contains an embedded Windows Media Player ActiveX® control and a script that continuously reconnects the Player to different files and live streams. In either case, connecting one or two clients to the server continuously should give you a good indication of the health of the server and network.

To configure Windows Media Load Simulator for online monitoring, select a sampling of source files and live streams for the simulated clients to play, and then enter one client in either the Play or Seek profile. If your content is encoded for multiple bit rates, use the Select profile instead.

You should not run stress or peak usage tests against an online server over the Internet or a network used by others. Windows Media Load Simulator can consume bandwidth rapidly, and the test will impact all other traffic on that segment of a network. By overloading the server with simulated clients, you impact service to all users connecting to the server. Online monitoring is a confidence monitor that checks for server and network health from the point of view of a typical client. The results you get from offline stress tests by using Windows Media Load Simulator are valid for the server when it is online. You should not need to perform additional stress testing when the server is online.

Windows Media Load Simulator contains a security feature that helps to prevent unauthorized users from running simulations against your servers. As described earlier, the WMLoad.asf file must be present in the Windows Media root directory of the Windows Media server before you can run a simulation. To help prevent unauthorized simulations from occurring while you are running Windows Media Load Simulator, configure authentication settings on the Windows Media server and then associate an access control list (ACL) with WMLoad.asf. The Windows Media server then verifies the access privileges of every user attempting to run Windows Media Load Simulator against the access rights you set on WMLoad.asf.

Enhancing the Online Monitor

You can configure the registry on the client computer so that Windows Media Load Simulator opens a program or runs a script when a test error is generated. This can be very useful when you must monitor the server or multiple servers continuously. You can, for example, create a script by using Microsoft Windows Script Host 2.0 or Microsoft Visual Basic® Scripting Edition that opens a message box or plays an audio file to alert an administrator. You can also create a script that sends an e-mail message to the network administrator. For more details about this approach, see Windows Media Load Simulator Help.

 Caution   Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
To configure the system registry, locate the registry key HKLM\Software\Microsoft\WMLoad and add a new string value with the name LogProgram. Type the path of the executable program file as the value. When Windows Media Load Simulator opens the program, it passes the following three arguments to the program.

One of the following strings that describe the error:




Name of the Windows Media server being checked.
Path of the log file, if required by your program.

If you want Windows Media Load Simulator to open a scripting program and pass to it the name of a script file, add a new string value with the name LogProgramArg. Type the path of the script file as the value.

Depending on the approach you choose, you might want to stop the simulation when an error occurs. For example, Windows Media Load Simulator sends an e-mail message every time an error occurs and the server stops responding, Windows Media Load Simulator continues to attempt to simulate client connections and sends an e-mail message each time the connection fails. In the Test Duration area of the Load Test Configuration (Advanced) dialog box, you can select the Stop After check box and type a number. When the error count reaches that number, the simulation stops.

For More Information

For details about server performance and tuning, see Optimizing Windows Media Services.

For more information about Microsoft Windows Scripting Technologies, including the Microsoft Windows Script Host, see the Windows Script home page.

Back to the top of this pageBack to Top

© 2017 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies