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.
