jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gomes Rodrigues <ra0...@gmail.com>
Subject Re: Some JMeter (technical) concerns
Date Mon, 30 Oct 2017 17:13:04 GMT
2017-10-30 18:07 GMT+01:00 Philippe Mouawad <philippe.mouawad@gmail.com>:

> On Mon, Oct 30, 2017 at 5:10 PM, Emilian Bold <emilian.bold@protonmail.ch>
> wrote:
>
> > 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 https://jmeter-plugins.org/ => 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).
> >
> Yes
>
> >
> > >>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 YaMeter.com 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 ?
>
> For me if my remember are good, it's easy

And the licence is apache

https://github.com/bulenkov/Darcula

I can make a try this week




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

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