Hi Oliver, Any solution that works for you is the good solution :) Yet in case of central CSV repository I'd be a bit concerned about delays introduced by requesting and delivering the data from the central repo.
Cheers, Janusz On 30 December 2013 20:20, Oliver Erlewein <[email protected]> wrote: > Hi Janusz, > > Cool solution to the problem. My other issue is with the distribution of > CSV files in a remote JMeter scenario. There's just no good solution. So > what I did I detailed here: > http://hellotestworld.com/2013/11/08/jmeter-csv-data-for-remote-clients/ > > It's not right for every scenario but it works wonderfully for me. I like > that I can have a central CSV repository and then easily access it. > > Cheers Oliver > > > On 7 November 2013 23:07, Janusz Kowalczyk <[email protected]>wrote: > >> Hi Oliver, >> >> Have a look at this test plan >> https://github.com/kowalcj0/jmeter-example-test-plans/tree/master/selectNRandomLinesFromFile >> There's a JSR223 Sampler which takes a text file and randomly selects N >> number of lines from it (sometimes with duplicates) and saves it in a new >> file. >> If you modify it to simply skip the first (header) line and then it might >> be what you're after. >> >> Cheers, >> J >> >> >> On 7 November 2013 06:47, Philippe Mouawad <[email protected]>wrote: >> >>> you might be interested in this discussion: >>> - >>> >>> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201310.mbox/%3cCAH9fUpZtWGR7nMhpCAROoKhsRhCGWLhksPb9CrD=8gvsrya...@mail.gmail.com%3e >>> >>> >>> >>> On Thursday, November 7, 2013, Oliver Erlewein wrote: >>> >>> > Oooh! I like that idea! That would also make it easier for me to update >>> > CSVs as they don't need to be distributed to the clients anymore! Would >>> > mean a bit of work but would be totally worth it. >>> > >>> > >>> > >>> > On 7 November 2013 11:46, Tim Koopmans <[email protected] <javascript:;>> >>> >>> > wrote: >>> > >>> > > 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] >>> <javascript:;> >>> >>> > >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] >>> <javascript:;>> >>> >>> > 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 >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> >>> > > >>> > > >>> > >>> >>> >>> -- >>> Cordialement. >>> Philippe Mouawad. >>> >> >>
