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: Improve our percentiles computation
Date Thu, 16 May 2019 08:21:08 GMT

Am 15.05.19 um 21:56 schrieb Philippe Mouawad:
> Hi Felix,
>
> Thanks for your feedback.
> Few questions below
>
> On Wed, May 15, 2019 at 9:40 PM Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Am 15.05.19 um 17:28 schrieb Philippe Mouawad:
>>> Hello,
>>>
>>> I'll start with my team the development of a switch to better percentiles
>>> computation which will end as a PR contribution.
>>>
>>> To recap previous discussions:
>>>
>>>    - We have currently 2 implementations of Percentiles :
>>>       - A custom one used in old listeners
>>>       - A new one based on commons-math
>>>       - CONS:
>>>    - It impacts maintainability as a consequence
>>>       - The results are different which confuses users
>>>       - Percentiles are not explicitly documented regarding the algorithm
>>>       used which also creates confusion :
>>>          - https://github.com/apache/jmeter/pull/295
>>>          - https://github.com/apache/jmeter/pull/296
>>>       - Benefits:
>>>       - Have one algorithm in codebase
>>>       - Rely on best percentile algo for our use case
>>>       - Rely on performing and reliable library HdrHistogram/LatencyUtils
>>>       - Improve CO handling
>>>    - PREVIOUS ACTIONS:
>>>    - It was agreed that switching to HdrHistogram was a good option. This
>>>       library is a standard now:
>>>          - Used in MicroMeter (used by Spring)
>>>          - Used in future JMC
>>>
>> https://mail.openjdk.java.net/pipermail/jmc-dev/2019-May/000984.html
>>>       - Felix started a PR:
>>>          - https://github.com/apache/jmeter/pull/380/files
>> I updated the branch and thus the PR to be hopefully more correct than
>> the old one.
>>
>> I still have a few doubts about the implementation. It seems to me, that
>> HdrHistogram is good for collecting the stats, but not optimized for
>> asking the stats a lot while the test is running.
>>
> Which would affect GUI mode testing only right ?
I believe so.
> If confirmed we would need to reduce refresh rate ?
Which would probably get us a few angry mails. We could live with that,
I think.
>
>> That is the reason, that I tried to implement the calculation of some of
>> those stats myself. There is a good change, that I completely messed it up.
>>
> you mean " There is a good chance, that I completely messed it up."

Right.

Felix


>
>>>       - Vladimir mentioned LatencyUtils in this PR:
>>>          - Used in MicroMeter
>>>          - Based on Gil Tene work who is master of CO related issues as
>>>          long as other titles
>>>
>>>
>>> *PROPOSED ACTION PLAN:*
>>>
>>>    - We'll start our work using LatencyUtils which seems interesting as
>> it
>>>    provides a PauseDetector which will be useful in our case
>>>
>>>
>>> If you have any note on this, feel free to add your ideas in this thread.
>> Have a look at the performance of the reports while the stats are
>> collected.
>>
> Thanks
>
>> Felix
>>
>>> Regards
>>> Philippe M.
>>> UbikLoadPack Team
>>>
>>>
>>>
>>>
>>>
>>>
>>> <https://www.openstreetmap.org/#map=18/50.69454/3.16455>
>>>
>

Mime
View raw message