[
https://issues.apache.org/jira/browse/POOL-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14150913#comment-14150913
]
Bernd Eckenfels edited comment on POOL-278 at 9/28/14 3:19 AM:
---------------------------------------------------------------
I wanted to keep that outside of the scope of POOL-277 because it kind of
resulted in a major restructuring without beeing able to proof performance
benefits. And since its my first contribution, I kept it simple.
I would make this a two step process, first make the interface public (so it
can be performance tested as well), and then actually modify the
implementation: It does looks like the updating formula but wrongly used (it
asumes index=0 is the oldest entry which it is not).
I don't like the current "last 100 values" approach anyway, as those values
could cover from milliseconds to hours. So an approach with a timer (similiar
to unix uptime) and knuth formular would be better. And finally, it would be
need to specify something like a
[metrics|https://dropwizard.github.io/metrics/] histogram object.
(automatically registered to JMX and stuff). Or maybe integrate with Commons
Math?
was (Author: b.eckenfels):
I wanted to keep that outside of the scope of POOL-277 because it kind of
resulted in a major restructuring without beeing able to proof performance
benefits. And since its my first contribution, I kept it simple.
I would make this a two step process, first make the interface public (so it
can be performance tested as wenn), and then actually modify the
implementation: It does looks like the updating formula but wrongly used (it
asumes index=0 is the oldest entry which it is not).
I don't like the current "last 100 values" approach anyway, as those values
could cover from milliseconds to hours. So an approach with a timer (similiar
to unix uptime) and knuth formular would be better. And finally, it would be
need to specify something like a
[metrics|https://dropwizard.github.io/metrics/] histogram object.
(automatically registered to JMX and stuff). Or maybe integrate with Commons
Math?
> Allow user provided efficient statistics implementations
> --------------------------------------------------------
>
> Key: POOL-278
> URL: https://issues.apache.org/jira/browse/POOL-278
> Project: Commons Pool
> Issue Type: Improvement
> Affects Versions: 2.3
> Reporter: Bernd Eckenfels
> Priority: Minor
> Labels: performance
>
> As discussed in POOL-277 there is some possibility to clean up the current
> StatsStore in impl/BaseGenericObjectPool. This would not only allow to get
> rid of the synchronized implementation and strange mean calculation, but also
> allow a user to register a faster or more complete statistics caluculation.
> For this I would suggest to make a Statisctics interface public and allow the
> user to register implementations of this interface for the various tracked
> metrics.
> This new interface should cover count, max, and mean. But the user can also
> directly use the object to ask it for percentile or other information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
