Another reason for using a stepped ramp is that it’s inefficient to restrict a test to a single level of virtual users.\u00a0 Most websites perform pretty basic functions, and these functions do not change much over time.\u00a0 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.\u00a0 It’s far more efficient to ramp up user load during<\/em> a single test, so that you can test all the desired user levels with the test cases running in parallel.\u00a0 This saves time, and allows you to ramp right up to the failure point in one test rather than guessing and running multiple tests.\u00a0 This also gives you a much better mix of users doing different test case steps at the same time, helping to prevent load surges.<\/p>\n Ok, so how do we actually configure the user ramp?\u00a0 This is the Load Configuration screen:<\/p>\n A basic load configuration<\/p><\/div>\n The first and most obvious setting is is the “Run for” setting – how long you want the test to run.\u00a0 From a user ramp perspective, this is the available time you have to ramp your user count.\u00a0 (Ignore the “Run maximum repeats” option for now.)\u00a0 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.<\/p>\n Next, we have the number of starting users.\u00a0 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.\u00a0 Normally, this will be set at the same value as the “Increase by” setting, unless you have a reason to change it.\u00a0 It’s also a good idea to set this number to a multiple of the number of load engines you are using.\u00a0 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.\u00a0 This helps keep the load engines from becoming unbalanced.<\/p>\n The most important part of the user ramp is handled by the “increase by”, “over”, and “every” settings.\u00a0 These settings control how many users are added per cycle, and how long we take to add them per cycle.\u00a0 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.\u00a0 Then I add the next ramp of 50 users over the next minute.\u00a0 Like this:<\/p>\n 1st minute: add 50 users randomly<\/p>\n 2nd minute: no users are added<\/p>\n 3rd minute: add 50 users randomly<\/p>\n 4th minute: no users are added<\/p>\n … and so on.\u00a0 In other words, the ramp period where we are adding users (the “over” setting) is included<\/em> in the cycle time (the “every” setting).\u00a0 Note that we can ramp continuously by setting the ramp period and the cycle time to the same value.\u00a0 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.<\/p>\n It’s also useful to note at this point that these settings also apply to the starting users.\u00a0 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:<\/p>\n 1st minute: add 100 users randomly<\/p>\n 2nd minute: no users added<\/p>\n 3rd minute: add 50 users randomly<\/p>\n 4th minute: no users added<\/p>\n … and so on.<\/p>\n Last, we have the ability to limit the total number of users added during the test.\u00a0 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.\u00a0 This is useful for very long running tests where we are examining the performance of the system over time, rather than continuously ramping load.\u00a0 Below that setting is the “maximum users” box.\u00a0 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.<\/p>\n 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.<\/p>\n![\"A](\"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-content\/uploads\/2010\/02\/100_user_load_config.png\" "\\"100_user_load_config\\"")