loadrunner The UNIQUE parameter feature is a mystery to...

  • perf-test.com need your contributions to build up a strong repository of performance engineering resources.

S

Scott Moore

Guest
The UNIQUE parameter feature is a mystery to me. If I select UNIQUE to be updated each iteration, and then check the value that tells it to continue in a cyclic manner when it runs out of users, isn't this supposed to cycle through for infinity? Why would it still show there are insufficient records in the Controller Vuser output window? I thought that was the purpose for making the selection. Any thoughts on this?
 
I have a similar experience that might help? My experience using that parameter without continue is that LR tries to pre-allocate how ever many rows it thinks it needs based on VUs and planned iterations. It also appears to work in blocks for each VU, so a series of rows will be grabbed by each VU. I haven't really experimented with the pacing/iterations algorithm to figure out exactly how it works, but I've learned 1. It definitely does not go and get a row when it needs it (as you might expect), and 2. To work data files from back to front on consumable data if I want to understand what gets used.
 
If I tell it to go in a cycle, it should not need to be > users. I thought that was the point of the selection of that feature.
 
Scott Moore, I will try to give more details: when you use unique parameters it will be indeed unique for each Vuser. let's say we have 5 Vusers and 30 items on a unique parameter If we select to manually assign 6 items per each Vuser. Vuser 1 will be assigned numbers 1-6 uniquely and will cycle them from 1 till 6 and back to 1 and so on. If we select auto mode, VuGen will try to split it up automatically You even a simulator to verify the distribution. hope this helps
 
At the start of the test all the existing values are divided between the vusers. Say you have 60 values, 20 vusers, and each vuser is supposed to get 3 values. All is well - each vuser is allocated its own chunk of 3 values, and there will indeed be an infinite cyclic iteration through these values. However, if you have only 50 values, i.e. number of values < number of vusers multiplied by chunk size, then you'll get the message that you mention, the one about insufficient records. So just make sure you have enough values to distribute among all the vusers.
 
When using unique , set the block size ... which will be equal to or greater than the number of iterations per user for the duration of the test
 
The LR assume that you select unique parameter because the application is expected to work with unique value. But if you have insufficient value for no. Of users, ex, you got only 5 values for 10 users, you can just duplicate the value to make it sufficient. I would always block set of values for users in this scenario.
 
OK, NOW this makes sense. I always thought that it would calculate the number of values it needed and just make it work when you selected it to go in a cycle, but it makes sense that it assumes you really do need it to be unique. If you are simply dealing with a situation where you might have some repeats toward the bottom and that is OK, just duplicate the data and make more lines. Thanks for this clarification.
 
This is a great feature but if you're using test data that can only be used once you can get problems. If a test fails part way through, you end up with data throughout your data file that can't be used again. You either need to write used data to an external file so that you can removed the "used" data from the original file or use VTS.