Hello, This has been implemented today within: - https://bz.apache.org/bugzilla/show_bug.cgi?id=62684
No additional CSV field was needed. It would be nice if you could review , test and give feedback. Regards On Fri, Jul 3, 2015 at 7:11 AM sebb <[email protected]> wrote: > On 1 July 2015 at 21:59, Philippe Mouawad <[email protected]> > wrote: > > Good idea Andrei indeed. > > > > How do you see it: > > > > - Would we add a new field called : > > - jmeter.save.saveservice.injid composed of host:port > > - Or would we ad jmeter.save.saveservice.port and require users to > set: > > - jmeter.save.saveservice.hostname=true > > - jmeter.save.saveservice.port=true > > - And compute the field from this. > > I prefer that. > > > > > One thing I find a bit bad is network traffic, as we repeat in batch > mode > > (default) this information uselessly > > > > For example for 100 results, we would transmit it 100 times while only 1 > > would be better. > > In which case the client would need to add the field back before > storing the record. > > > Note this applies to other fields like: > > jmeter.save.saveservice.filename=false > > > > But maybe it's another topic related to Network traffic optimization in > > Distributed testing, some ideas: > > Yes, that should be a separate discussion. > > > - Switch to Rest WS or Google Protobuf > > - Only send required data and no more serialized objects > > - .... > > > > > > Regards > > > > > > > > > > On Wed, Jul 1, 2015 at 10:24 AM, sebb <[email protected]> wrote: > > > >> On 1 July 2015 at 09:11, Andrey Pokhilko <[email protected]> wrote: > >> > Hi, > >> > > >> > Thanks for this initiative, I felt it painful for jp@gc, for > >> > Loadosophia.org and for my new project Taurus. > >> > > >> > I would solve it with hostname+port pair in SampleResult, as it makes > >> > >> Using port is an excellent idea. > >> > >> Maybe as host:port as that is a standard way of representing them. > >> > >> > easier to map results to originating JMeter servers. Unique ID's would > >> > also solve it, but it will require additional work to match ID back to > >> > server. And ID's are not obvious, so it's bad user experience. > >> > >> Agreed. > >> > >> > Andrey Pokhilko > >> > > >> > On 07/01/2015 01:46 AM, Philippe Mouawad wrote: > >> >> On Wednesday, July 1, 2015, sebb <[email protected]> wrote: > >> >> > >> >>> On 30 June 2015 at 22:16, Philippe Mouawad < > [email protected] > >> >>> <javascript:;>> wrote: > >> >>>> Hello, > >> >>>> When we do distributed testing and need afterwards to analyze > >> results, we > >> >>>> need to know how much threads were running at the some point in > time > >> by > >> >>>> doing aggregation work, as illustrated here: > >> >>>> > >> >>>> - http://jmeter-plugins.org/wiki/ActiveThreadsOverTime/ > >> >>>> > >> >>>> I am just illustrating this need by this particular plugin, but > this > >> need > >> >>>> is here whatever plugin or custom code is used to create this > graph. > >> >>>> > >> >>>> Currently as each server reports his own number of threads, and > this > >> is > >> >>>> then written to a file, we need a way to know that N number of > threads > >> >>> are > >> >>>> associated to X server. > >> >>>> > >> >>>> I suggest that when a test starts, JMeter client (controller) > computes > >> >>> and > >> >>>> sends to each server a unique ID, this id would then be stored by > the > >> >>>> server and accessible under a property or function. > >> >>> What's wrong with storing the hostname? > >> >>> > >> >>> usability and see below > >> >>>> This way, users would only have to add to their thread group name > this > >> >>>> additional property without any other configuration. > >> >>> Already possible; just use the hostname > >> >>> > >> >>> Not enough if you have 2 servers on 1 host > >> >>>> Another better options is to even remove the need for users to add > >> this > >> >>>> function / property by appending this information automatically > from > >> the > >> >>>> server in the thread name. > >> >>> I don't understand what you are proposing here. > >> >> > >> >> jmeter client assigns a unique id to each server that the latter > uses to > >> >> name thread and appends to thread group value leading to unique > values > >> and > >> >> possibility to copite the cumulated number of threads among all > servers > >> >> > >> >>>> Thoughts ? > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> Regards. > >> >>>> Philippe M > >> >> > >> > > >> > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. > -- Cordialement. Philippe Mouawad.
