I would go with injid, single field. Andrey Pokhilko
On 07/01/2015 11:59 PM, Philippe Mouawad 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. > > > 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. > 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: > > - 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 > >
