jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Some JMeter (technical) concerns
Date Mon, 30 Oct 2017 17:07:48 GMT
On Mon, Oct 30, 2017 at 5:10 PM, Emilian Bold <>

> Answers bellow:
> >1.1 Metrics
> >>I believe it is possible to add usage metrics to JMeter while respecting
> >> the ASF policy on privacy, etc.
> >>It's also unclear to me how download stats are not shared by the Apache
> >> mirrors (any ASF document explaining this policy?).
> >>
> >I agree with this.
> > I have asked Apache infra if we are able to get some metrics but it seems
> > it's not the case.
> > I am also very unhappy with this and have to default to:
> > - stackoverflow questions
> > - downloads of plugins
> > - user mails
> Can I start a discussion with ASF legal@, infra@ and the rest about how
> an Apache project could get some metrics or add "telemetry".
Yes go ahead

> >>2. Speed of development
> [...]
> > But another thing, did you have a look at the frequency at which user
> > upgrade ?
> Where would I see such info?

Not that simple, it is more something I see from our work and the answers
we provide on :

   - stackoverflow questions

   - the user mailing list

And also => Metrics are better IMO since user
see that upgrades exist

> > I still see a lot of people using version that are 5 year old, so if we
> > released more often, would user upgrade their versions ?
> They would, if JMeter would tell them about this and provide a simple
> one-click way to auto-update (think how Google Chrome autoupdates, etc).

> >>Are any companies putting resources into JMeter? I see a lot of companies
> >> / startups trying to make money off JMeter but how many are contributing
> >> back?
> >>
> >Not enough involvement in Core IMO:
> > - My company Ubik-Ingenierie contributes in 2 ways:
> > - Patches, bug fixes
> > - Bigger features like JMeter Web Report , JSON Plugin
> > - Sponsoring partly my time for working on project
> > I wonder for example why HTTP2 was not donated immediately to Core.
> Because it's better for them to control the plugin.

I am not sure.
As you can tell from your own discussion, being late on providing HTTP2 is
not a good point for JMeter and as such for any commercial product relying
on it IMO.
So in a way, providing it as a plugin and not in core is a mistake IMO.
I also find it a bit discouraging as a member of PMC to see so few
contributions from big players, and on that side also I find it's a big
mistake from
commercial project that make money from it not to contribute back to core.

I still hope this will change.

Hopefully we have contributions from individuals and it's great.

> >>BTW, one reason I decided to do instead of trying to push
> into
> >> JMeter proper is the approval speed. Getting a patch in seems to take a
> lot
> >> of effort and I can only imagine how long it would have take to try
> >> something as large as what I did with YaMeter.
> >>
> >I think we have made improvements in that field, have a look at PR and
> > Patches taken into account, look at thanks section of every released.
> > I don't think we are slow to take into account PR provided they are
> > complete. We give feedback in max 1 days AFAIK. For bugs it is even less.
> > I don't know statistics of other projects , but from my experience we are
> > good here.
> I guess the speed matters less if it's a one-off bugfix that you want to
> upstream.
> In my case, I had the time to contribute and felt it would have taken me
> forever to wait for each fix. Due to bad luck, this also happened near a
> JMeter release which implied a code freeze of sorts...
Yes it was that cause

> > Regarding YaMeter, I think we would have integrated it very quickly. I
> > wrote to you about it.
> I have to prepare multiple patches from YaMeter. The code is also using
> some NetBeans Platform frameworks so I would have to un-tangle those and
> use simpler things if I have to port it to JMeter as a plugin or something.

I'd be happy if you could but anyway good luck with it.

> > Regarding Undo, I was commited after the release, but as you know it is
> > still not satisfying .
> Yes, but not because of my patch which fixed quite a few things.
True. Your patch improved a lot but still feature is not mature enough yet.

> >>3. UI
> > JMeter UI is clearly a bad publicity for the core. I am always
> disappointed
> > to read tweet about JMeter looking very 90, being ugly ...
> >
> > The IDE is powerful but the Swing look is not great and some LAF are even
> > more awful , for example the Windows one are very ugly on some OSes.
> I believe YaMeter looks great and it's just a LnF (Darcula from IntelliJ).
> How about we add that to JMeter?
I'd love it !
Is it possible ?

> >>3.1 Swing
> >>If Swing remains the future of JMeter, I suggest looking into a better
> >> framework like Apache NetBeans Platform which provides a lot of useful
> >> things for desktop Java apps.
> >>Generally speaking, it would be good to split the UI from the "core" so
> we
> >> have some path where we evolve to some other UI.
> >>
> >If we had time , I would go for a full rewriting either in WEB or Using
> > Java FX, why not netbeans but I am not an expert of it. I am also very
> > impressed by IntelliJ look while it is in Swing AFAIK
> IntelliJ also has the IntelliJ Platform, just like Apache NetBeans
> Platform. Both are Apache 2.0.
> >>3.2 Web based
> >>Alternatively, a web-based interface could be made for JMeter. Any
> >> interest in this?
> >>
> >Yes , but always the same problem , no time
> This might be an interesting exercise.
> What sub-set of JMeter could we provide in the 1st release of a web UI?
> Just some HTTP request and a visualization would be a great start for users
> (this is where some metrics would help to see what users use most).

I don't know about that, what framework would you be using  ? What
architecture ?
I think this needs some architectural work to handle Plugins.
How would be provide the 2 UIs together ?
I feel it's a huge piece of work, but I am ready to go for it provided we
have some strong engagement from volunteers for some time.

On my side priorities are those ones and I would like to complete them ASAP:
- Completing HTTP Client 4.5 migration, I'm currently working on it

> >>4. Plugin Manager
> >>It seems unacceptable to me that JMeter does not have a Plugin Manager
> and
> >> a plugin portal with some lower-usage plugins (eg. mongodb).
> >>It's acceptable for other plugins to exist elsewhere, but those should be
> >> just another "PPA" (see Ubuntu PPA) or another "plugin repository" URL
> to
> >> register.
> >>
> >
> >I absolutely agree. When Andrei started his work on Plugin Manager, I
> wrote
> > that this feature should have been in JMeter core.
> How about JMeter provides a Plugin Manager out of the box in the next
> release?
> What's so complex about it?

Nothing, if you have a plan, go ahead, I'll be happy to merge PRs.

> >>5.1 HTTP2
> >>A major problem being the lack of an official HTTP2 plugin, which people
> >> have to take from elsewhere. Blazemeter is probably quite happy with
> their
> >> implementation being used since it funnels people into their services.
> >>
> >Did you get a confirmation from them that they would be ready to donate
> it ?
> They don't want to donate it, because it would imply losing control over
> the plugin and plugin update speed (which with them is a matter of
> hours while under Apache it would be days).

That's what I feared.
Very bad thinking IMO, we could for example work on more frequent releases
and an improvements of the release process.

> >>7. Module system
> >>JMeter is using a lot of reflection to reinvent its own quirky module
> >> system (which provides the way the plugins work).
> >>This needs some standardization work.
> >>The NetBeans Platform, for example, comes with its own module system that
> >> also supports OSGI bundles (another module system). Then, there's the
> >> service locator (for services) and the Java 9 modules.
> >>
> >Probably. OSGI is not a model for me. Too much headache.
> > JBoss modules was interesting but not enough documented.
> > Java 9 modules might be a good option.
> Just too much reflection right now. Standard Java services loader would be
> a improvement. I have to prepare some patches here too.

For me it's not a prioritary problem frankly. I see the current
architecture which is simple provides enough power and this is proven by
the number of plugins in the market.
Unless you have a full backward compat solution, I'm for now not convinced
about the benefit vs the sum of problems we'll face.

> >>8. Remote is using old technologies
> >>RMI is a killer in modern setups. It needs open ports on both the slave
> >> and master for communication which only makes sense within the same
> >> intranet and it's a pain to configure when using Cloud resources.
> >>The whole communication between JMeter client and servers should be
> >> rewritten using more modern protocols.
> >>
> >Absolutely, I think the future should be a rest webservice.
> Not necessarily. But something that requires an open port just on the
> slave.

Anything better than RMI :-)

> >>10. Packaging
> >>JMeter should be everywhere. Official Docker files, AMI images, etc.
> >>
> >Not sure, that's a too big scope. Why AMI and not other clouds ? Why
> docker
> > and not other technologies ?
> > I think we need to limit the scope and there is enough communauty to help
> > here as we already see that.
> Docker is pretty big. Amazon is pretty big. It doesn't matter which Cloud
> we target but we have to be more Cloud focused.

On this side, I am not convinced it should be in Core. But open to ideas.
If we go for providing a Cloud solution, I think JCloud should be used.
I don't want to privilege one Cloud provider unless we have some
involvement from that provider of course.

> --emi

Philippe Mouawad.

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