[infinispan-dev] Looking into OProfile logs

[Manik Surtani]

Also, lets please move this discussion to infinispan-dev… 


On 25 Jan 2012, at 17:57, Dan Berindei wrote:

> On Wed, Jan 25, 2012 at 6:32 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> On 25 January 2012 15:56, Dan Berindei <dan.berindei at gmail.com> wrote:
>>> On Wed, Jan 25, 2012 at 3:16 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>>>> 
>>>>  - ComponentRegistry.getComponent # can't we make sure this is not
>>>> needed at runtime, or create direct accessors for the hottest ones,
>>>> like Configuration.class ? I'll make a proposal and measure it.
>>>> 
>>> 
>>> I had an idea of registering lots of CacheInboundInvocationHandlers in
>>> CommandAwareRpcDispatcher instead of a single global
>>> InboundInvocationHandler but I never implemented it. Are you thinking
>>> along the same lines?
>> 
>> 
>> No I've been patching CacheRpcCommandExternalizer instead. But please
>> change that one if you have an idea.
>> 
> 
> Ok, I'll do that.
> 
>> 
>>>>  - DefaultConsistentHash.isKeyLocalToAddress # Should be possible to
>>>> speed up this one
>>>> 
>>> 
>>> I didn't think of any optimization specific for isKeyLocalToAddress,
>>> but we could precompute the list of owners for each hash wheel
>>> "segment" and store that in the positionValues array instead of a
>>> single address. It would get kind of expensive with huge numbers of
>>> virtual nodes, so it would be nice if we could prevent the users from
>>> using thousands of virtual nodes.
>>> 
>>> Address interning could help us somewhat, if we could eliminate the
>>> equals() calls with reference equality checks.
>> 
>> Right, but it means that all Address should be created via the same
>> service, including unmarshalled ones.
>> Would be nice doing it, but sounds like dangerous if not doing an
>> extensive refactoring.
>> I'd try something like this by introducing a new type, mandate the
>> type on the API, and do this possibly after changing the Address
>> collections to an ad-hoc Collection as suggested last week; not sure
>> yet how it would look like, but let's evaluate options after the
>> custom collections is in place.
>> 
> 
> I was actually thinking knowing that a1 != a2 => !a1.equals(a2) would
> enable us to use even more efficient custom collections.
> But I agree that replacing all addresses with interned ones is not an easy task.
> 
>>>> - boolean org.infinispan.transaction.xa.GlobalTransaction.equals(java.lang.Object)
>>>> # let's see if we can do something about this.
>>>> 
>>> 
>>> Checking the address is more expensive than checking the id, we should
>>> check the id first.
>>> Other than that, the only thing we can do is call it less often :)
>> 
>> And idea on "less often" ?
>> 
> 
> Nope, no idea I'm afraid.
> 
>>> 
>>>> - jni_GetObjectField # would like to know where this is coming from
>>>> 
>>> 
>>> It looks like it's PlainDatagramSocketImpl.send and receive:
>>> 
>>> 6184      0.2442  libnet.so                libnet.so
>>> Java_java_net_PlainDatagramSocketImpl_send
>>>  7483     34.3556  libjvm.so                libnet.so
>>> jni_GetObjectField
>>> 
>>> 3849      0.1520  libnet.so                libnet.so
>>> Java_java_net_PlainDatagramSocketImpl_receive0
>>>  8221     34.7773  libjvm.so                libnet.so
>>> jni_GetObjectField
>> 
>> Right, that's likely. Would like to make sure.
>> 
> 
> This is certainly a big part of where it's coming from - but perhaps
> there are other places as well.
> 
>> 
>>> I also have a question, are you using virtual nodes? We should enable
>>> it in our perf tests (say with numVirtualNodes = 10), I suspect it
>>> will make DCH.locate and DCH.isKeyLocalToAddress even slower.
>> 
>> We've discussed VNodes a lot on IRC, you should join us.
>> [My tests where without, but have already applied the patch to enable it]
>> 
> 
> I'm also going to update VNodesCHPerfTest to look closer at key distribution.
> 
> Cheers
> Dan

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org