jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: Ideas for 3.2
Date Sun, 27 Nov 2016 10:57:57 GMT
Am 23.11.2016 um 23:04 schrieb Philippe Mouawad:
> 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
Done

>
>> We could then use the cache library (was it caffeine?)
>
> Yes
Added a patch to the bugzilla entry.

>
>> 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.
I think we should document both additions :) But you are right grok 
might need more than a boundary based one.

I have a minimal implementation to translate grok expressions to regex 
expressions that gives - as a bonus - a set of names that will be used 
for the extracted varnames. So if a user gives a grok string of 
"%{NUMBER:count} Person" it would be translated into a regex string 
"(-?\d*(?:\.\d+)) Person" and the matching group would be stored into 
the var named "count" (count_... if more then one should be found, like 
in regex mode).

But I am still not sure about, wheter we should add a "mode"-switch to 
the regex extractor or add two new extractors.


>
>
>> 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.
Well, we added SLF4J as the backend for Excalibur logging and I know I 
refused to include patches, that switched from Excalibur logging to 
SLF4J API in the past. My question really was about which api we use in 
the JMeter code base.

1. stay with Excalibur (routed to SLF4J)
2. switch to SLF4j
3. switch to whatever is hip today

>
>
>> 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.
I thought we were waiting for commons to support it. But otherwise +1
>     - MQTT : There is a PR for this one
+-0 It would be another plugin to support and it could really live on 
its own.
>     - Undo/Redo : I sent a mail on this one and a possible way to implement
>     it
It would be nice to have it working, but it seems like an awful lot to 
do, to get it working.
>     - 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
I still think we should experiment in that direction, but it seems to be 
a really big step and shouldn't be done in a hurry.
>     - Websocket
There seems to be an external plugin already.
>     - 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.
The demo looked really intriguing, but I have no knowledge in that 
direction to help out.
>
> 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.
I JSON really that much more readable compared to XML?
>
> We wouldn't drop XML yet.
We shouldn't.

Regards,
  Felix
>
>
>
>> Regards,
>>
>>   Felix
>>
>>
>>
>


Mime
View raw message