Re: [infinispan-dev] Looking into OProfile logs

On Wed, Jan 25, 2012 at 6:32 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > On 25 January 2012 15:56, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >> On Wed, Jan 25, 2012 at 3:16 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; 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