'Insufficient records for parameter 'xxxx' in table to provide the Vuser with unique data

[Prateek Yadav]

Hi,

I am running a load test with 3000VU's distributed across 58 scripts and have some issues related to data distribution while running the scenario.

So, basically 'Insufficient records for parameter 'xxxx' in table to provide the Vuser with unique data' error occurs randomly in few scripts. Count of error changes test over test, even though settings are kept same. Below are my parameter file settings and one of the case which looks strange to me. This happens in many other scripts as well.

Error Message:

                                (Just In Time log mode).

                (Log messages will be sent only when an error occurs).

                (To change this behavior, look at the Log tab in Run Time Settings).

 

Start auto log messages stack.

Ending iteration 12.

Waiting 220.077 seconds for iteration pacing.

Starting iteration 13.

Error: Parameter 'PLNAME': No more unique values for this parameter in table 'XXXXXXXXXXXXX.csv' [unique range is 7441-7452]. The Vuser is aborted according to "When Out Of Values" policy.

End auto log messages stack.

 

Start auto log messages stack.

Ending Vuser...

Starting action vu.

vuser_end.c(4): lr_think_time: 5.00 seconds.

vuser_end.c(6): Notify: Transaction "S0" started.

vuser_end.c(40): Error: (0, 7453)

vuser_end.c(40): Error: Parameter 'DATABASE': Cannot replace the parameter with a value from table 'XXXXXXXXXXXXX.csv' [column=0, row=7453].

Setting:

Select Next Row : Unique

Update Value on : Each Iteration

When out of values:  Abort Vuser

Allocate Vusers value in the Controller : Allocate 40 values for each Vuser

No of users : 184

Total Data in file  : 7452

Now, 184*40 = 7360, so why data row 7441-7452 is assigned.

 

I think I shouldn’t get error with this setting mathematically, that too on 13 iteration. 

Thanks,

Prateek

[Bhushan]

Theoretically your settings are correct. Have you checked all values in param file are unique?

Another point is - how many positions across multiple scripts is this parameter being used? That could also lead to this issue. 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.
To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.
To post to this group, send email to LR-Loa...@googlegroups.com.
Visit this group at https://groups.google.com/group/LR-LoadRunner.
To view this discussion on the web visit https://groups.google.com/d/msgid/LR-LoadRunner/5d3e4908-fb11-4040-a44f-de3da5dbfa72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[aravind sai kuchibhatla]

Hi,

1) Check if you have given any other number apart from 1 in 'First data line' option.

2) Allocate Vusers value in the Controller : Allocate 40 values for each Vuser

If you have given this option and your iterations are less than 40(Suppose 20), Then load runner will count first 20 values(1-20) for User 1; 41-60 values for User 2; 81-100 values for User 3; 121-140 values for user 4 and son on...

That means it is reserving first 40 values for User 1 even though there are less number of iterations..

This might have caused issue for in your settings.. Check this as well.

Let me know the outcome after checking it.

[Prateek Yadav]

Hi,

Yes, all the parameters in the file are unique and since it has to fetch record in each iteration, it shouldn't matter how many times this parameter is called in the script.

[Prateek Yadav]

'First data line' is 1.

[Kevyland]

Review: http://easyloadrunner.blogspot.com/2014/03/sequential-random-unique-each.html

Are the parameters in the same *.csv? or different files.   

I usually don't allocate the range I set it automatic

For parameters in the same row I link to the primary unique row "Same line as" for the dependent rows

[Prateek Yadav]

It's in same *.csv files. And Ihave allocated a primary unique row as you mentioned, although it doesn't matter. LR's job is to allocate data uniquely(different row blocks, even if data is same) to virtual users.

[André Luyer]

Did you restart any Vuser during the run?

When a Vuser is restarted a new unique block is allocated.

André

[Rick Carter]

I can’t be 100% sure from reading through your information, so forgive me if you know this already, but every script that has “Unique” reads from the same file, so if you had for example:

5 VU of script1

and

5 VU of script2

and they read the same file and it’s set “Unique,” and you tell each you want 40 rows, you’ll need 40*(5+5) = 400 rows. When I first started with LoadRunner, I had that misunderstanding, assumed that script1’s unique wouldn’t conflict with script2’s unique. In my case, it was a data maintenance set of scripts, that I had to do a couple of different operations based on the same data, running multiple VUsers for speed. I discovered I had to make a copy of my .csv file for each script.

I always thought that it would be a cool enhancement to LoadRunner if you could have two flavors of Unique: Unique across all scripts using the same data file (current definition), and Unique across all VUs of a single script (but another script could use the same set of values for its own Unique).

- Rick

--

Rick Carter
Application System Administrator Senior
Information Technology Services
University of Michigan
+1-734-647-5941
rkca...@umich.edu

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.
To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.
To post to this group, send email to LR-Loa...@googlegroups.com.
Visit this group at https://groups.google.com/group/LR-LoadRunner.

To view this discussion on the web visit https://groups.google.com/d/msgid/LR-LoadRunner/0ac64ab4-c8cb-4117-a0b8-c2f6e244a882%40googlegroups.com.

[James Pulley]

I found the easiest way to ensure uniqueness across groups is to use a queue to feed all of the users.  Take your pick, VTS, Amazon simple queue service, roll your own with RabbitMQ or some such.   When there are no more data elements then you return -1 and kill your user.   You can use one user in a group that starts first to load up the queue and then once that group stops have the other groups start and begin feeding from the queue.   

This method is pretty tool agnostic as well.

James Pulley

NewCOE/LiteSquare/PerfBytes

To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunner+unsubscribe@googlegroups.com.

[Prateek Yadav]

Yeah. I used to do this while testing with VSTS, where unique option was not in-built(uptil 2010 atleast) and I had to pull data from SQL DB with a flag column set. I had thought of trying VTS, hoping it will overcome the issue, but thought of giving it a try here first, assuming it's too silly for a costly tool like LR to throw this error. Thanks for your suggestion anyways.

To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.

[Prateek Yadav]

Thanks for highlighting, but in this particular case, all the scripts have their own data file in their respective folders.

[James Pulley]

Your assertion on unique doesn't hold.   This was in at least the 5.x product line dating to 1997.  I pulled my training manual for LR 6.0 DB virtual user  from 1998: Page 2-17 covers unique read from table and page 2-22 covers Unique Number.

Unique holds within groups, but not across groups even with the same script name.   When you cross groups you either need decoupled data files for the virtual users to be unique or you need an external source which enforces uniqueness, hence feeding from a queue.

[Prateek Yadav]

@Andre. Thanks for your suggestion. I did multiple test to understand this behavior and figured out that restart due to application related errors were causing this to happen. My assumption that data block assigned to vuser remains same throughout the test, even if it's restarted, was wrong and hence users which were coming in the system at the end were failing due to insufficient data as data which I had allocated for them were used by the users which were restarted. This issue and no. of failures were inconsistent as application concurrency errors were inconsistent.