I did take a look at sirona, and it looks really nice.
Whats the best way to contribute to it? Any open issues you would like to
work somebody on?
Thomas
On Wed, Nov 20, 2013 at 5:38 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
yep but this is not enough, almost each component is doing
Hi
first maybe the thread should move over sirona list (I wouldn't bother
commons ;)): http://sirona.incubator.apache.org/mail-lists.html
about hot topics I think we have:
1) Gui enhancement (a jira is about using another js library to draw
graphes and get an analysis/correlation view, another
On 11/21/2013 11:14 AM, Romain Manni-Bucau wrote:
Hi
first maybe the thread should move over sirona list (I wouldn't bother
commons ;)): http://sirona.incubator.apache.org/mail-lists.html
about hot topics I think we have:
1) Gui enhancement (a jira is about using another js library to
Hi
A quick mail to give some feedbacks of my tests.
I started to hack a bit to get rid of not used stats by sirona,
typically I do ATM:
setSumsqImpl(NoopStat.INSTANCE);
setSumLogImpl(NoopStat.INSTANCE);
setGeoMeanImpl(NoopStat.INSTANCE);
(NoopStat is a mock of
On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
Hi
A quick mail to give some feedbacks of my tests.
I started to hack a bit to get rid of not used stats by sirona,
typically I do ATM:
setSumsqImpl(NoopStat.INSTANCE);
setSumLogImpl(NoopStat.INSTANCE);
next version (rewrite/fork):
https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
was easier to centralize everything in a single class
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
On 11/20/13, 7:26 AM, Romain Manni-Bucau wrote:
next version (rewrite/fork):
https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
was easier to centralize everything in a single class
That is exactly what I meant about
yep but this is not enough, almost each component is doing n++. This
is fast but since done under a lock if it can be removed it should.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github:
On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
Hehe, right.
I looked a bit more today and LongAdder is only a part of the
solution. The stat computation still needs to lock to get acces to
previous values (N - N+1). Basically the gain wouldn't be as
important as I thought :(.
Right, but I
well pool are based on locks so I'm not sure (it would need deep
benchs on a real app) it does worth it
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/6 Phil Steitz
On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
well pool are based on locks so I'm not sure (it would need deep
benchs on a real app) it does worth it
Commons pool2 uses pretty lightweight locking and using a pool of
instances achieves the basic objective of reducing contention for
the single
Great!
Btw not sure for sirona we oculd use it. One constraint on sirona-core
is to stay self contained. We already shade math3 so shading pool2 too
would start to create a big jar for this need. I'll try to bench
deeper next week too.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog:
On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
Great!
Btw not sure for sirona we oculd use it. One constraint on sirona-core
is to stay self contained. We already shade math3 so shading pool2 too
would start to create a big jar for this need. I'll try to bench
deeper next week too.
OK - and
On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
Oh sorry, that's what I said early, in a real app no or not enough to be an
issue buy on simple apps or very high thrououtput apps yes.
Le 5 nov. 2013 07:00, Ted Dunning ted.dunn...@gmail.com a écrit :
That
On 11/4/13 9:59 PM, Ted Dunning wrote:
That isn't what I meant.
Do you really think that more than one metric has to update (increment,
say) at precisely the same time?
Yes, that is the problem. For consistency, you need multiple
quantities atomically updated for any of the moment-based
Well I didnt test sirona in prod but when using jamon (same kind of
framework) locks were creating a serious overhead on some benches. Not the
most important but enough to try to solve it.
That said we are not yet in 1.0 so Im ok to wait for more serious feedbacks
if you think it is better
Le 5
@Phil: hmm can be but the framework would create its own overhead which
would be avoided with a dedicated solution, no? Well thought gain was great
for small investment but ok to postpone it
Le 5 nov. 2013 18:54, Romain Manni-Bucau rmannibu...@gmail.com a écrit :
Well I didnt test sirona in prod
Hehe, right.
I looked a bit more today and LongAdder is only a part of the
solution. The stat computation still needs to lock to get acces to
previous values (N - N+1). Basically the gain wouldn't be as
important as I thought :(.
As I said before we'll wait a bit to gather feedbacks, if it
My experience is that the only way to get really high performance with
counter-like objects is to have one per thread and combine them on read.
On Mon, Nov 4, 2013 at 8:49 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote:
Hi,
ATM sirona (a java monitoring library in incubator) relies a
Thats more or less what does LongAdder in a more clever way.
Le 4 nov. 2013 18:15, Ted Dunning ted.dunn...@gmail.com a écrit :
My experience is that the only way to get really high performance with
counter-like objects is to have one per thread and combine them on read.
On Mon, Nov 4, 2013
On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
Hi,
ATM sirona (a java monitoring library in incubator) relies a lot on
Summary stats object from [math3] but it needed a lock to ensure
consistency. I know there is a synchronized version but this one
scales less then the locked one.
My
But aggregation needs to lock so not a real solution. Lock is fine on real
cases but not in simple/light ones. ThreadLocal leaks...so a trade off
should be found
Le 4 nov. 2013 18:42, Phil Steitz phil.ste...@gmail.com a écrit :
On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
Hi,
ATM sirona
On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
But aggregation needs to lock so not a real solution. Lock is fine on real
cases but not in simple/light ones. ThreadLocal leaks...so a trade off
should be found
Depends on the use case. If the use case is
0) launch a bunch of threads and let
In sirona we collect (aggregate) data each N ms and we can still use stats
during aggregation (worse case surely)
Le 4 nov. 2013 21:48, Phil Steitz phil.ste...@gmail.com a écrit :
On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
But aggregation needs to lock so not a real solution. Lock is fine
On 11/4/13 12:58 PM, Romain Manni-Bucau wrote:
In sirona we collect (aggregate) data each N ms and we can still use stats
during aggregation (worse case surely)
Can you explain more clearly exactly what you are doing? What needs
to be aggregated when? How are the threads managed?
Phil
Le
I still think that what you need is a thread-safe copy rather than a
thread-safe mutate. Even if you force every thread to do the copy, the
aggregation still still wins on complexity/correctness/performance ideas.
On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
A counter has a stat object, then methods are intercepted and duration is
added to the stat object (1 by method). Value is copied each 4s.
Le 4 nov. 2013 23:23, Ted Dunning ted.dunn...@gmail.com a écrit :
I still think that what you need is a thread-safe copy rather than a
thread-safe mutate.
On 11/4/13 2:22 PM, Ted Dunning wrote:
I still think that what you need is a thread-safe copy rather than a
thread-safe mutate.
I was just thinking the same thing. Patches welcome.
Phil
Even if you force every thread to do the copy, the
aggregation still still wins on
The copy will lock too. And it doesnt solve leak issue of the one instance
by thread solution, no?
Le 4 nov. 2013 23:27, Phil Steitz phil.ste...@gmail.com a écrit :
On 11/4/13 2:22 PM, Ted Dunning wrote:
I still think that what you need is a thread-safe copy rather than a
thread-safe mutate.
On 11/4/13 2:31 PM, Romain Manni-Bucau wrote:
The copy will lock too.
Right. That is why I asked exactly how things work. If you can't
lock during aggregation, we need something different.
And it doesnt solve leak issue of the one instance
by thread solution, no?
Correct, again depends on
The copy doesn't have to lock if you build the right data structure.
The thread leak problem can be more serious.
On Mon, Nov 4, 2013 at 2:47 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 11/4/13 2:31 PM, Romain Manni-Bucau wrote:
The copy will lock too.
Right. That is why I asked
Am 05.11.2013, 00:44 Uhr, schrieb Ted Dunning ted.dunn...@gmail.com:
The thread leak problem can be more serious.
What Thread Leak problem? TLS is cited to have that leak since ages, I am
not sure I ever have seen one triggered. So, who has details on that? Even
the JCL uses (more) thread
Well before patching a consistent solution needs to be found.
Sorry to go back to LongAdder but the idea is to add instances but not as
much as thread. Just what is needed. It means you decrease the number of
instance to aggregate so the lock time.
The queue solution sounds worse since a queue
On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 11/4/13 3:44 PM, Ted Dunning wrote:
The copy doesn't have to lock if you build the right data structure.
The individual stats objects need to update multiple quantities
atomically when new values come in.
You cant stop the app cause you take a snapshot of the monitoring metrics
so yes
Le 5 nov. 2013 06:46, Ted Dunning ted.dunn...@gmail.com a écrit :
On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 11/4/13 3:44 PM, Ted Dunning wrote:
The copy doesn't have to lock
That isn't what I meant.
Do you really think that more than one metric has to update (increment,
say) at precisely the same time?
On Mon, Nov 4, 2013 at 9:49 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote:
You cant stop the app cause you take a snapshot of the monitoring metrics
so yes
Oh sorry, that's what I said early, in a real app no or not enough to be an
issue buy on simple apps or very high thrououtput apps yes.
Le 5 nov. 2013 07:00, Ted Dunning ted.dunn...@gmail.com a écrit :
That isn't what I meant.
Do you really think that more than one metric has to update
37 matches
Mail list logo
