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
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 to
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
wrote:
> yep but this is not enough, almost each "component" is doing n++. This
> is fast
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: https://github.com/rman
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 abo
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/
LinkedI
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);
> set
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 StorelessU
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 -
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: http://rmannibu
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 s
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/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, b
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 block
On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
> @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
As I said, patches welcome. Go for it. My point about
@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" a écrit :
> Well I didnt test sirona in prod but when using jam
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 no
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 s
On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
wrote:
> 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" a écrit :
>
> > That isn't what I meant.
> >
> > Do you rea
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" a écrit :
> That isn't what I meant.
>
> Do you really think that more than one metric has to update (increment,
> say) at p
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 wrote:
> You cant stop the app cause you take a snapshot of the monitoring metrics
> so yes
> Le 5 nov. 2013 06:46
You cant stop the app cause you take a snapshot of the monitoring metrics
so yes
Le 5 nov. 2013 06:46, "Ted Dunning" a écrit :
> On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz wrote:
>
> > On 11/4/13 3:44 PM, Ted Dunning wrote:
> > > The copy doesn't have to lock if you build the right data structu
On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz 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. Consistency in the copy
>
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 is
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. Consistency in the copy
requires that you suppress updates while the copy is in progres
Am 05.11.2013, 00:44 Uhr, schrieb Ted Dunning :
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 local objects. For exa
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 wrote:
> 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
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
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" 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.
>
> I was just
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 complexity/correc
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" a écrit :
> I still think that what you need is a thread-safe copy rather than a
> thread-safe mutate. Even if you force
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
wrote:
> In sirona we collect
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
> L
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" 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
> real
> > cas
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
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" a écrit :
> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> > Hi,
> >
> > ATM sirona (a java monito
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
Thats more or less what does LongAdder in a more clever way.
Le 4 nov. 2013 18:15, "Ted Dunning" 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 at 8:49 AM,
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 wrote:
> Hi,
>
> ATM sirona (a java monitoring library in incubator) relies a lot on
> Summary stat
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 question is quite simple then: will [math] add an implement
40 matches
Mail list logo
