If you're really into self-tuning this parameter, I expect that a very simple gradient-descent mechanism would actually work pretty well in this case.

We have done similar work in the Cloud-TM project (applied to both message batching and number of threads active per node), and if you're interested I may send more references on this.

BTW, +1 for making this configurable: eager broadcasting read requests seemed to me to be a little too aggressive for the normal/failure-free behavior.

Cheers,

Paolo

On 2/26/13 1:55 PM, Erik Salter wrote:

Tune in real-time, of course ;)

Erik

From: infinispan-dev-bounces@lists.jboss.org [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Mircea Markus
Sent: Tuesday, February 26, 2013 7:36 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Staggering remote GET calls

On 26 Feb 2013, at 10:56, Manik Surtani wrote:

I'm not surprised that read performance suffers a bit actually. Which is why we broadcast the GETs originally. But once the staggering timeout becomes configurable, this should be something people can tune.

+1. Also the performance increase for writes is huge. I think this should be the default, as read efficiency can be improved by L1.

Cheers,

--
Mircea Markus

Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev