We approach this problem slightly differently, albeit we use an external process ..
Users upload a CSV which we bulk import into redis. Users can then make HTTP requests to that data set via a performant API (webdis in front of redis). This allows calls like SPOP (remove a random member) or SRANDMEMBER (retrieve random member). This takes care of the headache of trying to carve up CSVs across your load generators[1] A little bit more effort, but may give you some ideas. Regards, Tim Koopmans <https://flood.io> Level 27, 101 Collins Street Melbourne, Vic 3000 [1] https://flood.io/blog/9-sharing-test-data On Thu, Nov 7, 2013 at 9:36 AM, Oliver Erlewein <[email protected]> wrote: > Hi Sergio, > > Sorry forgot to say that that isn't a good option for me. I thought about > it but I dynamically build remote agents off a standard build image and > that makes my start procedure immensely difficult as I'd need to split the > files and copy them to the clients before the test. I also don't have a > standard number of clients so the splits are different. If I do that I > could also just re-randomize my files too. > > Cheers Oliver > > > On 7 November 2013 11:28, Sergio Boso <[email protected]> wrote: > > > Il 06/11/2013 23.20, Oliver Erlewein ha scritto: > > > > Hi all, > >> > >> I'm sure that this is a common problem for those using JMeter executions > >> across several machines. Can't really find any solution to this. So here > >> goes: > >> > >> I have a plan that looks something like this: > >> > >> Test Plan > >> |-- Thread Group > >> |--CSV Dataset > >> |--HTTP Sampler (login) > >> |--.... > >> > >> If I remotely distribute this all remotes will 1st start with line one > of > >> the CSV file. In my case this will cause locking in the application, > >> thereby destroying the test. Ideally I'd like to give the CSV file a > >> random > >> offset for each remote client, so that it would start iterating at > various > >> points in the CSV. This is not quite safe but should give me enough > >> variance so that the chance of locking would be minimal. > >> > > The only way I have found to cope with this is to manually split the CSV > > file, and copy each of these parts to each remote system, so that each > > system uses its own set of lines. > > > > I'm looking forward to see if there is a better system > > regards > > > > Sergio > > > > -- > > > > Ing. Sergio Boso > > > > > > > > >
