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 Sun, 27 Nov 2016 12:54:29 GMT
On Sun, Nov 27, 2016 at 11:57 AM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

> 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
>
Thanks

>
>
>> We could then use the cache library (was it caffeine?)
>>>
>>
>> Yes
>>
> Added a patch to the bugzilla entry.
>
I reviewed, +1 for commit

>
>
>> 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.
>>
>
Done. Should we remove HTML and HTML+embedded resources renderer ?
I think we should.

>
>> 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.
>

Using Regexp has the advantage that users will see this new feature, but
might complexify UI but maybe not. Could you share your UI or patch ?.
But no strong opinion on this.

>
> 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
>

I would tend to switch to SLF4J and drop excalibur, we can potentially name
next version 4.0 to break more compatibility things, although I am
convinced we don't loose much by dropping current logging configuration.

>
>
>>
>> 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?
>
JSON is more readable but the XStream one might not be, I can investigate
this more



>
>> We wouldn't drop XML yet.
>>
> We shouldn't.
>
I agree

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


-- 
Cordialement.
Philippe Mouawad.

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