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: Ideas for 3.2
Date Wed, 23 Nov 2016 22:04:13 GMT
Hi Felix,
I am happy too see such enthusiasm !


On Wed, Nov 23, 2016 at 10:16 PM, Felix Schumacher <felix.schumacher@
internetallee.de> wrote:

> Hi all,
>
> now that we released 3.1, it is time to think about the next release.
>
> I think we should update the minimum version of java to 8 (as discussed
> before).
>
+1

>
> We could then use the cache library (was it caffeine?)


Yes

> and use javafx for html widgets (I would like to see them used for
> documentation and template-selection, too).
>
I will be commiting the patch for Browser.

And +10 for your ideas

>
> Philippe has proposed to add a boundary based extractor, which I believe
> could be massaged into the normal regex extractor together with a grok to
> regex converter.
>

Yes , go for Grok
But I think boundary may also be useful in addition to Regex. From what I
saw (but maybe I missed something) , it does not seems as easy as that to
use Grok, the boundary extractor is a not brainer, user just put what he
bounds the data he wants to extract.
Grok requires a minimum of documentation reading no ?
Of course I may be wrong Felix, if I missed something please explain.


> We discussed the memory usage of the results tree view, where we could not
> agree on the implementation. I believe this could be combined with a filter
> that sorts samples out, before they even get into the tree view. That could
> be used to filter on thread ids or session id, or even (when implemented as
> a queue) to emit only those samples, that were collected shortly before an
> error (or other event).
>

+1

>
> Logging. We made the start to use slf4j. Should we change the remaining
> classes too?
>

AFAIK, HttpComponents directly migrates to LOG4J2. But I am ok for SLF4J.
I believe we should not try to migrate existing functionnality of JMeter,
just plug SLF4J and select log4j2 as implementation and use default
configuration mechanism. I think we have a lot of other work related to
CORE features of a load testing tool and should not spend too much energy
on this part.

We could ask on twitter if users use Logging configuration in JMeter.


> The documentation has still the pdf howtos, which could be converted to
> html and looked through, if they still work.
>
+1

>
> Drop generated docs from the source tree.
>
No opinion

>
> Add source-jars to the maven artefacts.
>
+10, it has been requested.

>
> What are your plans / vetoes? I am sure I missed quite a bit.
>

I would add as TOP priority but more effort:

   - HTTP/2 : This one should be high priority, this one will soon be very
   popular and we should implement it.
   - MQTT : There is a PR for this one
   - Undo/Redo : I sent a mail on this one and a possible way to implement
   it
   - Your idea: possible rework of core architecture to at least introduce
   a pool of threads or switch to async model allowing us to take advantage of
   async io
   - Websocket
   - Ajax solution : ParallelController ? or another idea an HTTP Sampler
   that could contains a children SubRequest and we would reuse partly what we
   have for download embedded resources


In a previous discussion we had a LOOOOONNNG discussion on DSL.

This seems a bit complex. I am still not convinced that it is useful in all
fields, but it is useful for:

   - easily coding (REST) Services Load Testing. With Microservices
   popularity, this is an argument I think
   - Ease source control comparison in this case. And more widely when
   comparing tests

Couldn't we start simply by trying to replace XML by JSON as an
output/input format ? XStream has an implementation for this.

We wouldn't drop XML yet.



> Regards,
>
>  Felix
>
>
>


-- 
Cordialement.
Philippe Mouawad.

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