+1. I have to build dashboards on this event.
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Adrian Nistor
Sent: Friday, October 12, 2012 8:17 AM
To: Mircea Markus
Cc: infinispan -Dev List
Subject: Re: [infinispan-dev] State transfer performance
Hi Mircea,
Seeing Radim's mail makes me think we need a new event. We already have a
TopologyChangedEvent but this one is only useful to find out when a new CH
starts to be installed and when installation ends. With NBST actual state
transfer still continues a while after this and there is no programmatic way
to tell when it ends (except for some very ugly polling for pendingCh ==
null). Wouldn't it make sense to introduce a new event to signal end of
state transfer? I think for performance testing we should not rely on log
analysis because the logging itself slows everything down quite a lot and
has an undesirable impact on the results.
We already have the polling I mentioned in our unit tests in
TestingUtil.waitForRehashToComplete(). Removing those busy polling loops
might even make the tests run faster.
Adrian
On 10/12/2012 02:52 PM, Radim Vansa wrote:
Hi,
yes, we did this kind of tests for ispn 5.1 releases. There was pretty
easy to analyze the join time parsing the logs for debug messages from
CacheViewsManagerImpl, one such example is
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-60-radargun-e
lasticity-tx/5/artifact/report/loganalysis/views.html
However, currently there is no such obvious start/end: I have created
a log parser isolating some info (note that this is from two
consecutive runs in radargun with two configurations)
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/ispn-52-radargun-
resilience-dist-tx/37/artifact/report/loganalysis/statetransfers.html
It is not as nice, but still better than the logs itself.
Therefore, if we should benchmark some interval, we have to exactly state
which
events should be the start and end. Could you suggest anything?
We should also define the type of load. Should be the load random, or
should we let each client query for one key and check when it is able to
acquire the key and when we have to wait for long (because the segment with
this key is transferred)?
Radim
----- Original Message -----
| From: "Mircea Markus" <mircea.markus(a)jboss.com>
| To: "infinispan" <infinispan-dev(a)lists.jboss.org>, "Martin
Gencur"
| <mgencur(a)redhat.com>
| Sent: Friday, October 12, 2012 1:16:04 PM
| Subject: [infinispan-dev] State transfer performance
|
|
|
|
| Hi ,
|
| One of the targets of NBST is to minimise the downturn in throughput
| during topology changes. And now that NBST is getting there, I think
| that a test to measure how long does it take to a node to join,
| under different levels of cluster load, is very desirable in order
| to see where we are and also to help us profile and improve the
| state transfer performance.
| Martin, are we doing this kind of performance testing? It would be
| nice to have it integrated in Radargun or something similar in order
| to be able to quickly run it.
|
|
|
|
|
| Cheers,
| --
| Mircea Markus
| Infinispan lead (
www.infinispan.org )
|
|
|
|
|
| _______________________________________________
| infinispan-dev mailing list
| infinispan-dev(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev