Scalable approach to maintaining data files for simulations in Gatling

So I have been part of building a framework with Gatling and we were thinking if there is a scalable way to maintain CSV files for large number of simulations.

What we want to achieve:

  1. A single data file might be used by multiple simulations
  2. A single csv file contains multiple values and few of the values are used by 1 simulation and other set of values are used by other simulations
  3. Be able to have a default data file for each simulation
  4. Be able to override default data file if required and pass a new data file from may be command line.
  5. In some cases I would want that if I am running 10 simulations and I want to override input data file for just 1 simulation that should be possible as well.

Given above requirement and from my knowledge of JMeter I am thinking of following approach:

  1. Hardcode input data file for each simulation through feeder
  2. Have environment variable read in the framework and use them to override default data files for respective simulation. But this would mean having a lot of environment variables in framework i.e. 1 env variable for each simulation so we can override input file just for the simulation that we want for:

String envVarToGetInputDataFileNameForEachSimulation = System.getEnv(key_of_variable);

Limitations and questions:

  1. Is hardcoding csv files for respective simulations a good idea?
  2. When number of simulation grows, usually in enterprise frameworks that you build for your organisations do we maintain so many csv files? or use some other way?
  3. If I want to override a default file as stated in approach point 2., is it good idea to use 1 environment variable for 1 simulation? or is their a better way? And in this approach won’t we end up creating too many environment variables as number of simulation grows?
  4. Any other input from folks who have built large gatling frameworks and managed large number of input files can you please suggest a better and scalable way of doing it?

Hey fellow Gatling experts, your comments advice and solutions are highly appreciated on this question. Kindly respond at the earliest pls


Your question is very broad so it’s impossible to answer here.
Gatling uses code so you can really build your test in a way that matches your organization’s needs.

Here are a few pieces of advice:

  • split into reusable components that you can compose instead of having a huge monolith.
  • have distinct repositories per application so you can delegate maintaining them, instead of having one humongous monorepo (unless you’re a very large organization that has all the processes, tooling and experience for working this way).
  • use the Lightbend Config to manage configuration. Use configuration to define configuration profiles that would resolve multiple parameters: selecting injection profiles, selecting enabled scenarios or scenarios pieces, selecting feeders, etc

Kindly respond at the earliest pls

Kind reminder, this is a community forum. SLA and support are something that comes with paying subscriptions.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.