How User Ramping Works – Part One

How we add new virtual users to a test can be confusing when you’re first starting out with Load Tester, and sometimes can result in tests that do not ramp up to the number of users you expect or otherwise behave strangely.

To start, why do we even ramp up load?  Why not start with a set number of users?  We’ve covered that question in a previous blog post.

Another reason for using a stepped ramp is that it’s inefficient to restrict a test to a single level of virtual users.  Most websites perform pretty basic functions, and these functions do not change much over time.  You could perform multiple tests at each desired user level, but that takes as much time as it takes the users to run through the test cases for each test, which can be quite substantial.  It’s far more efficient to ramp up user load during a single test, so that you can test all the desired user levels with the test cases running in parallel.  This saves time, and allows you to ramp right up to the failure point in one test rather than guessing and running multiple tests.  This also gives you a much better mix of users doing different test case steps at the same time, helping to prevent load surges.

Ok, so how do we actually configure the user ramp?  This is the Load Configuration screen:

A basic load configuration

A basic load configuration

The first and most obvious setting is is the “Run for” setting – how long you want the test to run.  From a user ramp perspective, this is the available time you have to ramp your user count.  (Ignore the “Run maximum repeats” option for now.)  You can set this to whatever you want subject to your own time constraints, the memory available to record results, and enough data to supply the needs of the test cases that would take place over that time period.

Next, we have the number of starting users.  We allow this to be set independently to allow for cases where many users need to be started at once, and also cases where you want to start with a large number of users and then add a trickle of users as the test progresses.  Normally, this will be set at the same value as the “Increase by” setting, unless you have a reason to change it.  It’s also a good idea to set this number to a multiple of the number of load engines you are using.  For example, if you are working with five load engines, you should start with 10, 20, or 50 users rather than 17 or 32 users.  This helps keep the load engines from becoming unbalanced.

The most important part of the user ramp is handled by the “increase by”, “over”, and “every” settings.  These settings control how many users are added per cycle, and how long we take to add them per cycle.  For example, if I ramp by 50 users over one minute every two minutes, that means I add 50 users randomly over the course of the first minute, and then I wait one minute until the two minute cycle time is up.  Then I add the next ramp of 50 users over the next minute.  Like this:

1st minute: add 50 users randomly

2nd minute: no users are added

3rd minute: add 50 users randomly

4th minute: no users are added

… and so on.  In other words, the ramp period where we are adding users (the “over” setting) is included in the cycle time (the “every” setting).  Note that we can ramp continuously by setting the ramp period and the cycle time to the same value.  However, a stepped ramp as described here is much more useful, as it allows you to view the performance of the system at that user level without the strain of new users coming on-line.

It’s also useful to note at this point that these settings also apply to the starting users.  For example, if I configure the starting users at 100 and the ramp at 50 users over one minute every two minutes, my first few minutes will actually look like this:

1st minute: add 100 users randomly

2nd minute: no users added

3rd minute: add 50 users randomly

4th minute: no users added

… and so on.

Last, we have the ability to limit the total number of users added during the test.  This allows you to ramp quickly to a predetermined number of users, and then run at that level for a period of time without adding new users.  This is useful for very long running tests where we are examining the performance of the system over time, rather than continuously ramping load.  Below that setting is the “maximum users” box.  This isn’t a configuration option, but rather a quick calculator to show you how many users your current ramp will add given the current test duration.

In part two, I’ll talk about how users are distributed across the load engines, as well as the cases where Load Tester can behave differently than you might expect given the settings you’ve configured.

How User Ramping Works – Part Two.

Matt Drew

Add Your Comment

You must be logged in to post a comment.



Copyright © 2017 Web Performance, Inc.

A Durham web design company


For Prices Call (1) 919-845-7601 9AM-5PM EST

After hours? Prefer email? Just complete this form and we will get back to you as soon as possible with a quote. Please note: Technical support questions should be posted to our online support system.

About You
Product Needs

Request a Quote

Our experienced performance engineers have tuned hundreds of systems for companies large and small, and know just where to look, saving you time to market and money. We'll run your website through a complete performance evaluation, then tell you exactly how many users your site can support, including such important details as the effects of "the last mile." We'll also pinpoint potential problem areas and give you a full report detailing what needs to be fixed and where.

About You
Product Needs