{"id":823,"date":"2010-04-19T16:37:33","date_gmt":"2010-04-19T20:37:33","guid":{"rendered":"http:\/\/www.webperformanceinc.com\/load_testing\/blog\/?p=823"},"modified":"2012-02-01T14:34:31","modified_gmt":"2012-02-01T18:34:31","slug":"how-user-ramping-works-part-two","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2010\/04\/how-user-ramping-works-part-two\/","title":{"rendered":"How User Ramping Works – Part Two"},"content":{"rendered":"

In part 1<\/a> of How User Ramping Works, we discussed how to set up a user ramp configuration for a test.\u00a0 When you’ve done that, recorded and replayed your test cases to perfection, loaded your datasets, configured your load engines, and set up your server agents, what actually happens when you push the big green button?<\/p>\n

The first thing Load Tester does is go through a setup sequence that configures the load engines for the coming test.\u00a0 This can take a while, especially if you’ve configured large datasets or large numbers of files to be uploaded during the test – at least some of that data has to be transferred to every load engine to provide data for the virtual users.\u00a0 How, precisely, that happens is important because it can affect your test.<\/p>\n

First, if you have only one load engine, all the data will be uploaded to that load engine.\u00a0 If you have multiple load engines, what gets uploaded where depends on how the Sharable option is set for each dataset.\u00a0 If the Sharable option is enabled (checked), complete copies of the dataset will be uploaded to all the load engines and used independently by each load engine.\u00a0 As noted in the help, enabling the Sharable option means that multiple virtual users can and will use the same dataset row at the same time.\u00a0 For example, if your dataset consists of usernames and passwords, you can expect that there will be multiple logins of that user across several different virtual users.\u00a0 Additionally, when multiple load engines are in use, this means that the same user account can and likely will be logged in from multiple IP addresses as well.<\/p>\n

If the Sharable option is not<\/em> enabled (unchecked), then Load Tester splits the dataset up as evenly as possible across the load engines.\u00a0 For example, if you have three load engines and a 3,000 row dataset, each load engine will get 1,000 rows of data.\u00a0 This split is sequential, not random – load engine #1 will get rows 1-1000, load engine #2 will get rows 1001-2000, and so on.\u00a0 This tries to ensure that dataset rows are not in use by different virtual users on different load engines at the same time.<\/p>\n

Once the upload and configuration process is complete, Load Tester instructs the load engines to begin the test.\u00a0 The first group of virtual users is added randomly throughout the first ramp period.\u00a0 When you’ve only got one load engine, all the users are added to that load engine, if it has enough CPU and memory to add those users.\u00a0 If you have multiple load engines, how the users are distributed depends on an algorithm that tries to optimize the balance of users across the load engines.\u00a0 Simply put, the controller tries to add the new user to the load engine with the highest estimated capacity.\u00a0 The capacity calculation is based on the number of current users on that load engine versus the CPU\/memory usage, and is recalculated every few seconds.\u00a0 For example, if a load engine has 100 users and is at 50% CPU and memory usage, the estimated capacity will be approximately 200 users.<\/p>\n

This can result in a situation where the load engines become unbalanced, with one or two load engines supporting most of the virtual users.\u00a0 Sometimes this is what you want, such as when you have one large and powerful load engine and a few smaller supporting load engines.\u00a0 However, this can (and often does) cause a number of problems.\u00a0 The most common and most confusing problem caused by unbalanced load engines is virtual users running out of dataset rows.<\/p>\n

For example, assume that you have a 200-row dataset of usernames and passwords which is used for logins.\u00a0 That dataset is split evenly across two load engines, #1 and #2, so each load engine gets 100 rows.\u00a0 The test is configured to run up to 200 virtual users.\u00a0 However, during the test, the load engines become unbalanced, and load engine #1 reaches 100 virtual users first … and then tries to add the 101st virtual user.\u00a0 That virtual user will throw an error and terminate, because all 100 rows of the dataset on load engine #1 are in use and he cannot obtain a row for use in his test case.<\/p>\n

How can we stop that problem from occurring?\u00a0 The best way is to have more dataset rows than you’ll think you need.\u00a0 If you have two load engines as above, a dataset with 400 rows will make sure that, even if one load engine takes all<\/em> the load, you’ll still have enough dataset rows to service the virtual users.\u00a0 Failing that, you can use identical or similar load engines, which avoids hardware-based imbalances; you can use our Instant Load Engine bootable CD to equalize the environment on the load engines and avoid interference from other OS operations; and, perhaps most importantly, you can set the number of starting users on the test to be a multiple of the number of available load engines – this will help make sure that each load engine gets off on the same footing.\u00a0 It also helps to have a larger number of starting users – 10 per load engine is a good rule of thumb.<\/p>\n

During the test, Load Tester is continually instructing the load engines to add users during ramp periods.\u00a0 However, you may notice that sometimes users do not get added, and that ramp periods go by without users being added.\u00a0 This can happen for a variety of reasons, but the most common occurrence is when you are using the local load engine and the engine is memory-constrained.\u00a0 You can either address this by adding more memory to the controller (and the local engine) by editing the webperformance.ini file in the Load Tester installation directory, or you can use external load engines that have more resources available.\u00a0 You will not receive errors in this case, so if you’re having trouble getting to the proper user count, check your memory settings first.<\/p>\n

Finally, when the test ends, you’ll notice that it doesn’t actually stop.\u00a0 This is because we do not want to leave the target site in an unusual state, for example with large numbers of active sessions that are suddenly cut off, yet remain in the session tracking system until they time out.\u00a0 When the test ends, each virtual user will attempt to finish the current test case.\u00a0 Once that’s finished, the virtual user will terminate.\u00a0 This causes a ramp-down period with a minimum length equal to the duration of the longest test case, plus any delays incurred by the load test.\u00a0 If you don’t want to wait, you can hit the red button in the Status view to immediately terminate all virtual users, or you can configure that behavior to be the default in the Preferences.<\/p>\n

Happy testing!<\/p>\n

Matt Drew<\/p>\n","protected":false},"excerpt":{"rendered":"

In part 1<\/a> of How User Ramping Works, we discussed how to set up a user ramp configuration for a test.\u00a0 When you’ve done that, recorded and replayed your test cases to perfection, loaded your datasets, configured your load engines, and set up your server agents, what actually happens when you push the big green button?
\nThe first thing Load Tester does is go through a setup sequence that configures the load engines for the coming test.\u00a0 This can take a while, especially if you’ve configured large datasets or large numbers of files to be … Continue reading »<\/a><\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[50,71,33],"class_list":["post-823","post","type-post","status-publish","format-standard","hentry","category-load-tester-software","tag-load-engine","tag-user-ramp","tag-virtual-user"],"_links":{"self":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/823","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/comments?post=823"}],"version-history":[{"count":10,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/823\/revisions"}],"predecessor-version":[{"id":3111,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/823\/revisions\/3111"}],"wp:attachment":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/media?parent=823"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/categories?post=823"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/tags?post=823"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}