jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Distributed testing and active threads over time
Date Thu, 06 Sep 2018 05:39:23 GMT
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 <jmetertea@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 <sebbaz@gmail.com> wrote:
> >
> > > On 1 July 2015 at 21:59, Philippe Mouawad <philippe.mouawad@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 <sebbaz@gmail.com> wrote:
> > > >
> > > >> On 1 July 2015 at 09:11, Andrey Pokhilko <apc4@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 <sebbaz@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message