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-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@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 <http://www.infinispan.org>)
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
