Hi Janusz,

The repo answers within 15-20ms for CSV files that are a few thousand lines
long. For me that impact is negligible.

Cheers Oliver


On 3 January 2014 13:43, Janusz Kowalczyk <[email protected]> wrote:

> 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.
>>>>
>>>
>>>
>

Reply via email to