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 2018/09/05 21:35:11 UTC
Re: Distributed testing and active threads over time
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>.
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.
>