On 1/26/12 6:58 PM, Mircea Markus wrote:
> Hi,
>
> As discussed on another thread, I've hacked the remote get to only go to a
> single node. The performance of put almost doubled, whilst the one of gets
> decreased by about 10 percent.
> The performance decrease for gets is understandable, but I
Regarding ISPN-1786, I'd like to work with Sanne/Mircea on trying out
the new UNICAST2. In my local tests, I got a 15% speedup, but this is
JGroups only, so I'm not sure how big the impact would be on Infinispan.
If we see a big speedup, UNICAST2 and NAKACK2 could then be backported
to a 3.0.4,
On 26 Jan 2012, at 22:37, Sanne Grinovero wrote:
>>
>> Yes, we should profile a session with vnodes enabled.
>
> Manik, we're using VNodes in our performance tests. The proposal is if
> we can provide a good default value, as the feature is currently
> disabled by default.
I'm also concerned a
I really didn't want to do this, but it looks like a 5.1.1 will be necessary.
The biggest (critical, IMO, for 5.1.1) issues I see are:
1. https://issues.jboss.org/browse/ISPN-1786 - I presume this has to do with a
bug Mircea spotted that virtual nodes were not being enabled by the config
parse
On 26 January 2012 22:29, Manik Surtani wrote:
>
> On 26 Jan 2012, at 20:16, Sanne Grinovero wrote:
>
> +1
> Which default? 100? A prime?
>
> We should also make sure the CH function is optimized for this being on.
>
>
> Yes, we should profile a session with vnodes enabled.
Manik, we're using VNo
On 26 Jan 2012, at 20:16, Sanne Grinovero wrote:
> +1
> Which default? 100? A prime?
>
> We should also make sure the CH function is optimized for this being on.
>
Yes, we should profile a session with vnodes enabled.
--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani
Lead, Infinispa
So you reckon we're better off looking at Sanne's design for transferring locks
and state separately? Sanne, when you do have a moment, it would be good to
document this up on the wiki and share it. :)
On 26 Jan 2012, at 17:43, Dan Berindei wrote:
> On Thu, Jan 26, 2012 at 7:17 PM, Manik Sur
+1
Which default? 100? A prime?
We should also make sure the CH function is optimized for this being on.
On Jan 26, 2012 8:12 PM, "Pete Muir" wrote:
> I think if we are confident it will benefit all, we should turn it on.
>
> On 26 Jan 2012, at 18:54, Mircea Markus wrote:
>
> > Hi,
> >
> > ATM
I think if we are confident it will benefit all, we should turn it on.
On 26 Jan 2012, at 18:54, Mircea Markus wrote:
> Hi,
>
> ATM the default value for virtualNodes is 1. This means that the wheel-share
> each node has can be very uneven[1] for smalls(up to 15 nodes) clusters.
> Increasing th
Hi,
ATM the default value for virtualNodes is 1. This means that the wheel-share
each node has can be very uneven[1] for smalls(up to 15 nodes) clusters.
Increasing this value even to a small number(10-30) would significantly improve
each node's share of wheel and the chance for a well balanced
On 1/26/12 5:43 PM, Dan Berindei wrote:
> On Thu, Jan 26, 2012 at 7:17 PM, Manik Surtani wrote:
>> On 26 Jan 2012, at 16:05, Sanne Grinovero wrote:
>>
>>> On 26 January 2012 10:36, Manik Surtani wrote:
Dan,
Looking through what we currently have, given the blocking nature of state
> Well, thats what I want to try and understand. If periodic flushing is
> easier/quicker/less risky to implement, I think we could do it for 5.2.0. :)
>
> Sanne, have you documented your design on separate transfer of state vs locks
> on the wiki somewhere? I'd be curious to see what Paolo a
On 26 Jan 2012, at 10:36, Manik Surtani wrote:
> Dan,
>
> Looking through what we currently have, given the blocking nature of state
> transfer, I wonder if we can improve on it by pausing the state transfer from
> time to time to flush waiting transactions? I.e., if state transfer is in
> p
On Thu, Jan 26, 2012 at 7:17 PM, Manik Surtani wrote:
>
> On 26 Jan 2012, at 16:05, Sanne Grinovero wrote:
>
>> On 26 January 2012 10:36, Manik Surtani wrote:
>>> Dan,
>>>
>>> Looking through what we currently have, given the blocking nature of state
>>> transfer, I wonder if we can improve on i
Master should be 5.2.0-SNAPSHOT.
We haven't created a branch for 5.1.x yet, but I'd hold back on that until we
really need one. 5.1.0.FINAL is tagged so that should be good enough.
Cheers
Manik
On 25 Jan 2012, at 23:05, Sanne Grinovero wrote:
> Hello all,
> I couldn't find a 5.1 branch, and
On 26 Jan 2012, at 16:05, Sanne Grinovero wrote:
> On 26 January 2012 10:36, Manik Surtani wrote:
>> Dan,
>>
>> Looking through what we currently have, given the blocking nature of state
>> transfer, I wonder if we can improve on it by pausing the state transfer
>> from time to time to flush
On 26 January 2012 10:36, Manik Surtani wrote:
> Dan,
>
> Looking through what we currently have, given the blocking nature of state
> transfer, I wonder if we can improve on it by pausing the state transfer from
> time to time to flush waiting transactions? I.e., if state transfer is in
> pro
Dan,
Looking through what we currently have, given the blocking nature of state
transfer, I wonder if we can improve on it by pausing the state transfer from
time to time to flush waiting transactions? I.e., if state transfer is in
progress and a write command or transaction is waiting for it
On 26 Jan 2012, at 14:52, Sanne Grinovero wrote:
> On 26 January 2012 14:37, Mircea Markus wrote:
I'd like to have Dan's input on this as well first, as he has worked with
remote gets and I still don't know why null results are not considered
valid
:)
>>>
>>> Pre-5.0 during
On 26 January 2012 14:37, Mircea Markus wrote:
>>> I'd like to have Dan's input on this as well first, as he has worked with
>>> remote gets and I still don't know why null results are not considered valid
>>> :)
>>
>> Pre-5.0 during state transfer an owner could return null to mean "I'm
>> not su
>> I'd like to have Dan's input on this as well first, as he has worked with
>> remote gets and I still don't know why null results are not considered valid
>> :)
>
> Pre-5.0 during state transfer an owner could return null to mean "I'm
> not sure", so the caller would ignore it unless every targe
21 matches
Mail list logo
