{"id":2136,"date":"2011-05-02T11:05:36","date_gmt":"2011-05-02T15:05:36","guid":{"rendered":"http:\/\/www.webperformance.com\/load_testing\/blog\/?p=2136"},"modified":"2011-05-02T13:20:42","modified_gmt":"2011-05-02T17:20:42","slug":"testing_data_population","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2011\/05\/testing_data_population\/","title":{"rendered":"Load Testing Data Population: How Many Rows?"},"content":{"rendered":"

A common problem when setting up a load testing configuration in Load Tester is figuring out how many rows of data you need for a particular test.\u00a0 For example, you need to have a set of user names and passwords to be used during the test, but how many do you need to ensure that the test will complete?<\/p>\n

To answer this question, you need to know three things: the duration of the test, the expected duration of the test case, and how many concurrent users the test will simulate.\u00a0 Fortunately, these things are usually easy to determine.\u00a0 The test duration is set by you in the load configuration:<\/p>\n

 <\/p>\n

\"Setting<\/a>

Setting the test duration in Load Tester<\/p><\/div>\n

 <\/p>\n

Next, you need to know the expected test case duration.\u00a0 Fortunately, Load Tester calculates this value for you in the Test Case Editor View:<\/p>\n

 <\/p>\n

\"Load<\/a>

Load Tester calculates the test case duration automatically<\/p><\/div>\n

 <\/p>\n

As a rule of thumb, round to the nearest minute and round down if possible .\u00a0 This number is not always accurate, as it does not include test case looping (the Restart Options tab in the right-click Test Case Properties dialog on a test case) nor does it take into account page processors that will refresh a page repeatedly while waiting for a particular result.\u00a0 In such cases, you will need to manually estimate the test case durations you are likely to see.\u00a0 In general, it’s a good idea to lowball the test case duration estimate, as the test will only fail if you come up short; having too many dataset rows is never a problem for the test.<\/p>\n

Finally, the number of concurrent users is also set by you in the load configuration:<\/p>\n

 <\/p>\n

\"Configuring<\/a>

Configuring Maximum Users<\/p><\/div>\n

 <\/p>\n

Note that the maximum users field is calculated from the fields above it, and is not directly set.<\/p>\n

Now that we have the key information we need, how do we put it together?\u00a0 Well, if all the users in a test started at the very beginning and continued to the very end, the calculation is simple:\u00a0 the number of users times the test duration divided by the testcase duration (rounded up) will give you the number of dataset items used.<\/p>\n

Visually, we might represent such a test something like this (Calculation #1):<\/p>\n

 <\/p>\n

\"The<\/a>

The Simplest Case<\/p><\/div>\n

 <\/p>\n

So we multiply the number of users (4) by the test duration (60 minutes) divided by the testcase duration (13 minutes), with the test duration\/testcase duration value rounded up:<\/p>\n

4 * (60\/13) = 4 * 5 (was 4.6) = 20<\/p>\n

So we need 20 rows of data to satisfy the data demand for this test.<\/p>\n

Of course, most load tests ramp up during the course of the test, instead of starting all the users at the beginning.\u00a0 If your data creation process is automated, you could use this simple method and it would overestimate, but would work.\u00a0 However, if your data creation is time-consuming or manual, you probably want a better estimate of how many data rows you actually need.\u00a0 A more standard load test would look something like this (Calculation #2):<\/p>\n

 <\/p>\n

\"The<\/a>

The Normal Case<\/p><\/div>\n

 <\/p>\n

Estimating the number of rows necessary in this case is just like calculating the area of a triangle in high school geometry – divide the previous calculation by two.\u00a0 As long as the user ramp is even and terminates within one test case duration of the end of the test, this estimate will be accurate.<\/p>\n

What about in the case of a test where you want to ramp up to a certain number of users, and then hold at that level for an extended period of time?\u00a0 In such a case, to estimate the number of data rows needed, split the test into two parts for the purposes of the estimate – one in which you’re ramping, and one in which you’re holding at a fixed user level:<\/p>\n

 <\/p>\n

\"Separate<\/a>

Separate Calculations For Different Test Sections<\/p><\/div>\n

 <\/p>\n

Once you calculate both of these values, add them together to get the total number of dataset rows needed.\u00a0 You can use this technique to estimate for any test, even one that ramps unevenly – simply divide up the test sections into ramping periods and load periods, estimate those, and then add them all together.\u00a0 You must also do the same for tests with multiple test cases if the test case durations are not similar.<\/p>\n

Finally, you want to pad the end estimate to protect the test from running into issues where the load engines become unbalanced – we usually recommend adding at least 25% to the estimate.\u00a0 When one load engine has significantly more virtual users than the others and the datasets are divided evenly amongst the load engines, that engine is at risk of running out of data before the others.\u00a0 In addition to the padding, you may also need to apply a user limit to that load engine, or even all the load engines, to ensure that they do not get out of hand.<\/p>\n

We’ve provided a calculator for calculation #2<\/a> with 25% padding on our site.<\/p>\n

Happy Testing!<\/p>\n

Matt Drew<\/p>\n

Web Performance Test Engineer<\/p>\n","protected":false},"excerpt":{"rendered":"

A common problem when setting up a load testing configuration in Load Tester is figuring out how many rows of data you need for a particular test.\u00a0 For example, you need to have a set of user names and passwords to be used during the test, but how many do you need to ensure that the test will complete?
\nTo answer this question, you need to know three things: the duration of the test, the expected duration of the test case, and how many concurrent users the test will simulate.\u00a0 Fortunately, these things are usually easy to determine.\u00a0 The test duration … 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":[8],"tags":[32,125,237,124],"class_list":["post-2136","post","type-post","status-publish","format-standard","hentry","category-load-testing","tag-calculator","tag-data-estimates","tag-load-testing","tag-load-testing-data"],"_links":{"self":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/2136","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=2136"}],"version-history":[{"count":31,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/2136\/revisions"}],"predecessor-version":[{"id":2174,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/2136\/revisions\/2174"}],"wp:attachment":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/media?parent=2136"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/categories?post=2136"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/tags?post=2136"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}