0
votes

I am running loadrunner to test the my API. However with concurrent users (Vusers = 100) I am getting the error that "test aborted due to lack of parameters). When I checked the log I see that some of the member Ids in the file (parameterized in script) are not used at all and even some of them are duplicated. I want that loadrunner would select unique values for each hit and not repeat any value.

The scenario parameters

  1. VuGen Script contains my request to the API, with 2 parameterized components. i.e member IDs and date.
  2. Member IDs 100,000 ids supplied in the file.
  3. Settings :
    a. Select next row: Unique
    b. Update value on: Each Iteration
    c. When out of values: Abort user
    d. Allocate 1000 values to each Vuser
    e. No. of Vuser (goal scenario) = 100
    f. Load generators = 2
    g. Test run time = 15mins
  4. Load Runner version = 12.01
1
Actual error stack trace : Error: Parameter 'member_id': No more unique values for this parameter in table 'member_id' [unique range is 2001-3000]. The Vuser is aborted according to "When Out Of Values" policy. - Anirban

1 Answers

0
votes

If you have a hard cut at fifteen minutes then not every user would have exhausted their block, as was the case with the virtual user message above - which should be expected when exhausting the data.

Alter your group execution policy to run until complete instead of running for a fixed duration. This is likely the root of why you have some finish and some not. As to the reuse, as this is by block size of number of rows, is there a chance of a repeating value in your 100K rows? I would use Microsoft Logparser to run a quick count and then a count only where you have distinct values. Should you see a difference in the two numbers then you have some repeating values....which would be pretty easy to have happen in a 100K value file.

Consider adding a third load generator (hardware matched) as a control group, running a single virtual user of each type. If this control group runs clean, with fast response times, and the two other generators (presumably independent of the controller) show slower response times, then your difference in the control group will point to an overloaded generator. Considering each one of your users is going to have a copy of that data file in RAM you may see a swap effect if any of the mdrv processes get swapped. For some reason non of the performance testing tool vendors mark their code as non-swappable....