The “Start users” for a test are all scheduled to begin within 10 seconds of the start time for the test. Each of these represents an individual virtual user which will pick one of your scenarios in the test according to the distribution defined in the plan. The virtual user will then proceed through the scenario steps with the specified pause times between each.
LoadStorm works much like a browser, so images and other static assets are cached as a particular scenario is run. For many scenarios, this means the first step is the biggest, since the subsequent steps do not request these cached assets again. As a result of this, tests will often show a high start load (based on requests and throughput), followed by a drop and then a steady increase over time. The virtual user load should still remain as specified in the load test from Start to Peak over the duration of the test.
The other virtual users (beyond the Start ones) are added as specified by the pattern over the remaining 90% of the test. So, you should reach the peak load at approximately 54 minutes into a 60 minute test. All virtual users stop after the test duration is reached, although there is sometimes a lag of a minute or more before they all get stopped. It doesn’t matter what step they are on at the end of the test, so a scenario may stop after step 1 out of 10 if the test duration is reached.
Timeouts and other errors on an html page will cause the scenario to stop executing, since steps are often dependent on prior steps for clicks or form processing. Errors and timeouts on image or javascript requests will cause that step to stop making more requests, but the scenario will continue on with the next step. At the end of a scenario (whether finished or stopped by error), a new scenario will be started approximately 5 – 10 seconds later with a brand new cache and everything reset. When the target web server slows significantly or starts having timeout errors, the execution of each scenario will slow as well.
For example, on a specific step let’s say there are 22 images, 2 stylesheets and a javascript file in addition to the html file. When last run from the UI in the build process, it took about 5 seconds to get all of these. You can see this on the page when adding a step. But, if each image takes 2 seconds instead of the normal fraction of a second, the step would then take 45 seconds or more and that scenario would proceed with the next step much later than expected. This is roughly what would happen with a real user, as they are not likely to move on until a page has finished rendering and images downloaded.
Turning off images and/or javascript can sometimes help to isolate problems, since these are often bandwidth heavy parts of the app but static files that require very little server resources. If there are no images served, but you have a high error rate, it is very likely you have a database bottleneck or app server problem. If things work fine with no images but fail when you are serving images, you probably are running into bandwidth limitations.