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
> >>
> >
>
--
Cordialement.
Philippe Mouawad.
