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-elasticity-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" <[email protected]>
> | To: "infinispan" <[email protected]>, "Martin Gencur" 
> <[email protected]>
> | 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
> | [email protected]
> | https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to