just trying to understand the best practice for allocating vusers to user paths via populations. we have converted our first full application for load testing to neoload from a different load test software and are trying to perform our first baseline tests. so the numbers listed below may not be what I should be using or I may not be allocating the vusers in a sensible way. or both..?
I have 8 user paths that perform various url calls. I setup 3 different populations for the user paths.
under populations I have all 8 user paths belonging to 1 of the 3 populations. each set with a rough % of the total vusers being used to equate to the correct number of vusers as closely as a % can with the numbers being used in our previous software. the following represents the allocation im currently using:
population #1 - 22 vusers
test #1 - 48% ~10.56 vusers (prev software 10 vusers)
test #2 - 13% ~2.86 vusers (prev software 3 vusers)
test #3 - 13% ~2.86 vusers (prev software 3 vusers)
test #4 - 13% ~2.86 vusers (prev software 3 vusers)
test #5 - 13% ~2.86 vusers (prev software 3 vusers)
population #2 - 13 vusers
test #1 - 70% ~9.1 vusers (prev software 9 vusers)
test #2 - 30% ~3.9 vusers (prev 4 users)
population #3 - 6 vusers
test #1 - 100% same for both
so in a scenario such as this how does neoload equate % such as this to real vuser allocation? if neoload is allocated say 4.6 vusers for a specific user path via the % of the population. does that mean it is using 4.6 vusers for that user path over time? or does that mean it is allocating 4 vusers for that user path over time and the .6 is just lost?
my suspicion is I need to have 8 populations in this scenario. or in any scenario where the % does not line up cleanly with the number of vusers to allocate. but I just want to make sure that is the case before telling my group that.
NeoLoad will always try to stick to your percentage of users per population but it will round up the values. For example, in population #2, you will probably have 9 and 4 users. You will never have .6 user.
so before i continue i just want to point out that my purpose is not to point out any failings in neoload. my only intent with this question is to get a better feel for best practices when creating populations.
with that in mind, i would assume it can't physically round up any further than i have actual dedicated vusers? For example lets assume i'm only running population 1. i dedicate only 22 vusers. while each would theoretically want to round up, i would suspect this would be impossible as it would require more vusers than i have physically dedicated to the test.
as a result the test is likely to run more along the lines of:
test#1 - 10 vusers
test #2 - 2 vusers
test #3 - 2 vusers
test #4 - 2 vusers
test #5 - 2 vusers
my suspicion is, based on neoloads logic, one or more of these tests would round up, but not all. several would have to round down to stay within my allowable 22 vusers.
so if my assumptions above are correct. i would assume a proper best practice would be to modify my total vuser count for the population to be something that works out to a whole number % wise. or simply split up the populations in a more intelligent manner? possibly even using a single population per test depending on the number of vusers i need to dedicate vrs % of allocation? im good with any of this being the solution, i just want to make sure my thinking is correct.
again, i don't see this as any type of limitation. i just want to make sure i fully understand how neoload would react so that we create populations/assign vusers in a way that makes sense to neoload and gives us the data we should expect.
I think you got it. You can either adjust the load of your population so the percentage does not have to be rounded up or like you said, you could use separate populations for your virtual users and use the exact number of virtual users that you would like to execute for each of them.
The first way is usually used when the exact number of profiles executed does not matter, only the proportion matters even if you have 1-2 more virtual users executed.
The second choice is better when you need the exact number of profiles executed.
