You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2015/06/30 23:16:33 UTC
Distributed testing and active threads over time
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.
This way, users would only have to add to their thread group name this
additional property without any other configuration.
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.
Thoughts ?
--
Regards.
Philippe M
Re: Distributed testing and active threads over time
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
clarified last note
On Wednesday, July 1, 2015, Philippe Mouawad <ph...@gmail.com>
wrote:
>
>
> On Wednesday, July 1, 2015, sebb <sebbaz@gmail.com
> <javascript:_e(%7B%7D,'cvml','sebbaz@gmail.com');>> wrote:
>
>> On 30 June 2015 at 22:16, Philippe Mouawad <ph...@gmail.com>
>> 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 group and appends to thread group value leading to unique
> values and possibility to compute the cumulated number of threads among all
> servers
>
>>
>> > Thoughts ?
>> >
>> >
>> > --
>> > Regards.
>> > Philippe M
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie
UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
Re: Distributed testing and active threads over time
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <se...@gmail.com> wrote:
>
>> On 1 July 2015 at 09:11, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> wrote:
>>>>
>>>>> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
>>>>> <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
>
>
Re: Distributed testing and active threads over time
Posted by Philippe Mouawad <ph...@gmail.com>.
I don’ think it’s related.
When did this issue appear ?
Could you open a new mail thread and give more details on what you do and
what you see in console and log ?
Regards
On Thursday, September 6, 2018, Jmeter Tea <jm...@gmail.com> wrote:
> Hello,
>
> It may not be related, but jmeterw isn't working on windows it write to
> console :
> JMeter"" was unexpected at this time.
>
> FYI
>
> On Thu, Sep 6, 2018 at 12:35 AM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
> > 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 <se...@gmail.com> wrote:
> >
> > > On 1 July 2015 at 21:59, Philippe Mouawad <ph...@gmail.com>
> > > 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 <se...@gmail.com> wrote:
> > > >
> > > >> On 1 July 2015 at 09:11, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> wrote:
> > > >> >>
> > > >> >>> On 30 June 2015 at 22:16, Philippe Mouawad <
> > > philippe.mouawad@gmail.com
> > > >> >>> <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.
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Distributed testing and active threads over time
Posted by Jmeter Tea <jm...@gmail.com>.
Hello,
It may not be related, but jmeterw isn't working on windows it write to
console :
JMeter"" was unexpected at this time.
FYI
On Thu, Sep 6, 2018 at 12:35 AM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
> 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 <se...@gmail.com> wrote:
>
> > On 1 July 2015 at 21:59, Philippe Mouawad <ph...@gmail.com>
> > 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 <se...@gmail.com> wrote:
> > >
> > >> On 1 July 2015 at 09:11, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> wrote:
> > >> >>
> > >> >>> On 30 June 2015 at 22:16, Philippe Mouawad <
> > philippe.mouawad@gmail.com
> > >> >>> <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.
>
Re: Distributed testing and active threads over time
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 1 July 2015 at 21:59, Philippe Mouawad <ph...@gmail.com>
> 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 <se...@gmail.com> wrote:
> >
> >> On 1 July 2015 at 09:11, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> wrote:
> >> >>
> >> >>> On 30 June 2015 at 22:16, Philippe Mouawad <
> philippe.mouawad@gmail.com
> >> >>> <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.
Re: Distributed testing and active threads over time
Posted by sebb <se...@gmail.com>.
On 1 July 2015 at 21:59, Philippe Mouawad <ph...@gmail.com> 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 <se...@gmail.com> wrote:
>
>> On 1 July 2015 at 09:11, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> wrote:
>> >>
>> >>> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
>> >>> <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.
Re: Distributed testing and active threads over time
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 1 July 2015 at 09:11, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> wrote:
> >>
> >>> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
> >>> <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.
Re: Distributed testing and active threads over time
Posted by sebb <se...@gmail.com>.
On 1 July 2015 at 09:11, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> wrote:
>>
>>> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
>>> <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
>>
>
Re: Distributed testing and active threads over time
Posted by Andrey Pokhilko <ap...@ya.ru>.
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
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.
Andrey Pokhilko
On 07/01/2015 01:46 AM, Philippe Mouawad wrote:
> On Wednesday, July 1, 2015, sebb <se...@gmail.com> wrote:
>
>> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
>> <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
>
Re: Distributed testing and active threads over time
Posted by sebb <se...@gmail.com>.
On 1 July 2015 at 07:34, Philippe Mouawad <ph...@gmail.com> wrote:
> On Wednesday, July 1, 2015, sebb <se...@gmail.com> wrote:
>
>> On 30 June 2015 at 23:46, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>> > On Wednesday, July 1, 2015, sebb <sebbaz@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>
>> >> <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
>>
>> I don't understand the usability issue.
>> How is it less usable than an unique ID?
>>
>> with my proposal the id is computed and sent by jmeter and as you propose
> we can add it as additional column in csv.
> While currenly user has to set a different one for each server, so more
> configuration and more risk of duplicates.
>
>>> > 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
>>
>> OK, true.
>>
>> >> > 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
>>
>> The thread group names are already quite complicated; does it make
>> sense to extend them further?
>>
>> Would it not be better to have a separate field with the server id?
>
> it is fine also for me
>
>
>> This could be the hostname plus an instance number, or it could be an
>> id
>
>
> Id is better for me
Why is an id better? Can you determine which two ids are on the same host?
>> that is not related to the hostname.
>> But I suspect that users will need to know which samples come from each
>> host.
>
> host is already a field no?
Optionally.
Would it work for it to be optionally replaced by host+id?
>>
>> This would make it easier to identify which records come from each
>> server instance.
>> Otherwise the group name will have to be split into separate parts for
>> analysis.
>>
>> >>
>> >> > Thoughts ?
>> >> >
>> >> >
>> >> > --
>> >> > Regards.
>> >> > Philippe M
>> >>
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Distributed testing and active threads over time
Posted by Philippe Mouawad <ph...@gmail.com>.
On Wednesday, July 1, 2015, sebb <se...@gmail.com> wrote:
> On 30 June 2015 at 23:46, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > On Wednesday, July 1, 2015, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >
> >> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>
> >> <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
>
> I don't understand the usability issue.
> How is it less usable than an unique ID?
>
> with my proposal the id is computed and sent by jmeter and as you propose
we can add it as additional column in csv.
While currenly user has to set a different one for each server, so more
configuration and more risk of duplicates.
>> > 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
>
> OK, true.
>
> >> > 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
>
> The thread group names are already quite complicated; does it make
> sense to extend them further?
>
> Would it not be better to have a separate field with the server id?
it is fine also for me
> This could be the hostname plus an instance number, or it could be an
> id
Id is better for me
> that is not related to the hostname.
> But I suspect that users will need to know which samples come from each
> host.
host is already a field no?
>
> This would make it easier to identify which records come from each
> server instance.
> Otherwise the group name will have to be split into separate parts for
> analysis.
>
> >>
> >> > Thoughts ?
> >> >
> >> >
> >> > --
> >> > Regards.
> >> > Philippe M
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: Distributed testing and active threads over time
Posted by sebb <se...@gmail.com>.
On 30 June 2015 at 23:46, Philippe Mouawad <ph...@gmail.com> wrote:
> On Wednesday, July 1, 2015, sebb <se...@gmail.com> wrote:
>
>> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
>> <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
I don't understand the usability issue.
How is it less usable than an unique ID?
>> > 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
OK, true.
>> > 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
The thread group names are already quite complicated; does it make
sense to extend them further?
Would it not be better to have a separate field with the server id?
This could be the hostname plus an instance number, or it could be an
id that is not related to the hostname.
But I suspect that users will need to know which samples come from each host.
This would make it easier to identify which records come from each
server instance.
Otherwise the group name will have to be split into separate parts for analysis.
>>
>> > Thoughts ?
>> >
>> >
>> > --
>> > Regards.
>> > Philippe M
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Distributed testing and active threads over time
Posted by Philippe Mouawad <ph...@gmail.com>.
On Wednesday, July 1, 2015, sebb <se...@gmail.com> wrote:
> On 30 June 2015 at 22:16, Philippe Mouawad <philippe.mouawad@gmail.com
> <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.
Re: Distributed testing and active threads over time
Posted by sebb <se...@gmail.com>.
On 30 June 2015 at 22:16, Philippe Mouawad <ph...@gmail.com> 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?
> 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
> 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.
> Thoughts ?
>
>
> --
> Regards.
> Philippe M