Hello Team,
I have a usecase which requires unique set of data to run. I am using multiple pods say ~4 as injector in Gatling enterprise. During the execution I see that the transactions fail for the use case which required unique set of data for ~60% of the time.
In script I am using “.shard” in feeder; still I see the same issue, tried with “.queue” as well but same issue.
val FNumber = csv(“xyz.csv”).shard or val FNumber = csv(“xyz.csv”).queue
Could you please suggest?
I suspect that as I am using multiple pods, each pod might be picking same value from feeder, resulting failure, as the application needs unique data.
However, If I use just 1 POD and run the test, it works perfectly fine.
Hello,
I suspect that as I am using multiple pods, each pod might be picking same value from feeder, resulting failure, as the application needs unique data.
There’s no way using shard can lead to record duplicates across a cluster of load generators. These feature has been stable for years and has an extensive test suite.
val FNumber = csv(“xyz.csv”).shard or val FNumber = csv(“xyz.csv”).queue
csv(“xyz.csv”).queue is wrong for your use case as it’s missing shard.
You must use shard to guarantee that no load generator use the same records.
You must use the queue strategy to guarantee that no virtual users pick the same records inside a given shard. Then, you can omit it as it’s the default strategy.
csv(“xyz.csv”).shard and csv(“xyz.csv”).shard.queue do the same thing as queue is the default strategy.
Could you please suggest?
Possible explanations:
- you’re missing
shard like in the val FNumber = csv(“xyz.csv”).queue you said you were using
- there’s a bug in your application, probably related to concurrency
- you have duplicates in your feeder file