The first step in configuring a load test is to select a test case, and use the right-click menu to select New Load Configuration:
The goal of a performance test is to determine a relationship between the number of virtual users and performance. In order to do that, you'll want to describe a ramping number of virtual users and observe the changes in performance relative to the number of users.
This section of the GUI allows the user to describe the performance test in terms of how quickly and often users will be added to the load test over time. In a typical load test, we will add a number of users over a period of time so that all of the users are not working on the same page of the testcase at any given moment. After adding users, we will wait for time, leaving the test in a steady state while Load Tester gathers aggregate data for later analysis.
It is best to start with a low number of users and verify the correct operation of your server before performing tests with larger number of virtual users.
The test configuration below shows a test that will run for 30 minutes, starting with 100 users, and increasing by 50 users every other minute. While the estimated maximum users that can be simulated by this configuration is shown as 800, the number of virtual users you can simulate is limited by the speed and memory of the load engine, so that the actual number of virtual users generated is potentially lower than the value in the "peak users" field.
Duration can be specified in units of hours or minutes. The duration of the test should change depending on your testing goals. If you are just trying to get an idea of the speed of certain operations on your site, useful performance information can be gained for tests that are a few minutes long. You can then tweak parameters in scripts or machine configuration and see if it has an effect on performance. If, however, you are trying to stress your web site to see if anything breaks, you'll want to run the test over a longer period of time.
Alternatively, it is also possible to have a test stop after repeating a fixed number of times. This approach allows the test to continue running for as long as the server requires, until the test has been attempted at least as many times as specified in the limit (or until the test is stopped by the user).
More than one test case can be run simultaneously by adding them to the table. To add a test case to the table select the test case with the pulldown box and then click on the plus "+" sign. The distribution of test cases is determined by the "Weight" column. For example, if you were going to simulate 100 virtual users, and wanted 20% of the load to be from test case 1, and 80% of the load from test case 2, you would put a weight of "20" for test case 1, and a weight of "80" for test case 2.
The "Speed" parameter describes the network bandwidth of each virtual user in the simulation. No matter what network configuration was used to record a test case, this setting controls the simulated network connection. For example, if the "Speed" parameter is set to 128 Kbps, that means the peak data transfer by each individual simulated user will not exceed 131,072 bits per second. (128 x 1024). This implies that if you recorded a business case over a local LAN, playing that testcase back at modem speeds will take much longer. The implications of the effects of bandwidth can be studied by running a Baseline Performance Report.
The sample period is the length of time over which metrics will be sampled before saving the values. For example, if the sample period is 15 seconds, the Metrics views showing the results of a test will have values every 15 seconds. This value should be shorter for short tests, and longer for long tests. For example, if your test only lasts an hour, then having samples every 10 seconds makes sense. If, though, your test is intended to run overnight, then the sample period should be much longer, in the area of 5 minutes. This helps make the data easier to interpret. When running extended tests, Web Performance Load Tester™ will collect large amounts of data - which could cause the program to run out of memory and halt the test prematurely. As a rule of thumb: when running a test for multiple hours, you should have sample periods that are on the order of minutes, while short tests can handle sample periods as small as 5 seconds.
For more information, please consult the section for the Load Test Configuration Editor.