> -----Original Message-----
> From: Emilian Bold [mailto:emilian.b...@protonmail.ch]
> Sent: Monday, 30 October, 2017 08:27
> To: dev@jmeter.apache.org
> Subject: Some JMeter (technical) concerns
>
> Compared to some of the plugins, JMeter seems to move very slowly. This
> might create the impression of stability but I believe it's just a sign of
> being resource constrained.
Workflow matters. Good tooling and process can allow a comparatively small
number of people hit well above their weight class. Someone needs to lead
the charge, though.
FWIW, In the time I've been following the project, it's definitely improved.
> 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.
Speaking from an engineering standpoint, I view the tight coupling of the
GUI to the internal representation and core functionality as _THE_ primary
long term blocker for the viability of the JMeter project as a whole.
> I find the whole configuration .properties file a very poor solution to
> the notion of a "project".
I think this is just another side effect of the tight coupling.
> The whole communication between JMeter client and servers should be
> rewritten using more modern protocols.
For this, I think the most important thing to pay attention to is the
usability and efficiency. Distributed execution of sophisticated test plans
is a 10x Advantage of JMeter; to my knowledge, this is the only tool that
can do it. So it'd be wise capitalise on that by making sure anyone else who
comes into this area has a tall order to be anything other than an also-ran.
> JMeter should think more about making it easy to be hooked up into a CI /
> CD pipeline.
Another place the GUI coupling hurts. I've recently been prototyping moving
our internal tooling to Gatling in large part because working with the
JMeter APIs is fraught with hazards and weird edge cases.
> The XML files are a pain to diff and people like to track / compare
> changes in modern devops shops.
More to the point, they're another coupling problem because they're a
serialisation. I have zero love for the JMX format after having to write
tools that work with it. Perhaps surprisingly, I think this _could_ be
resolved nicely without all of the other core work (rather, this would
probably facilitate that).
But it requires knowing what needs to be supported, first. (It ends up being
a language design problem.)
> Maybe a switch to YAML might suffice
Nah, that's just trading one ugly markup for another. Been done already.
Regards,
Wyatt
Confidentiality Notice: This electronic message transmission, including any
attachment(s), may contain confidential, proprietary, or privileged information
from Chemical Abstracts Service ("CAS"), a division of the American Chemical
Society ("ACS"). If you have received this transmission in error, be advised
that any disclosure, copying, distribution, or use of the contents of this
information is strictly prohibited. Please destroy all copies of the message
and contact the sender immediately by either replying to this message or
calling 614-447-3600.
