directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Inex branch merged into trunk...
Date Tue, 01 May 2012 23:43:33 GMT
Le 5/1/12 3:05 PM, Alex Karasulu a écrit :
> On Tue, May 1, 2012 at 4:08 AM, Emmanuel Lécharny<elecharny@gmail.com>wrote:
>
> o Object scope search (lookup) : 49 880 req/s compared to 23 081 on the
> previous trunk
> o One Level scope search (5 entries returned) : 68 715 entries returned
> per second, compared to 33 120/s
> o Sub Level scope search (10 entries returned ) : 70 830 entries returned
> per second, compared to 18 910/s
>
>
> This is great work Emmanuel. Nicely done!

I have some even better results, as of today :

o Object scope search (lookup) : 52 712 req/s compared to 23 081 on the previous trunk
o One Level scope search (5 entries returned) : 72 635 entries returned per second, compared
to 33 120/s
o Sub Level scope search (10 entries returned ) : 75 100 entries returned per second, compared
to 18 910/s


I have just removed the use of the getSearchControls() call, gaining 10% 
in perfs.
>
>
>> There is room for more improvement, but it will be more complex. The area
>> that can be improved are :
>> o get rid of the extra getSearchControls() call in intercepotrs. This is
>> the easiest fix
Done.
>> o review the way we handle entries modification before we return them.
>> Currently, we clone the entry, and remove the attributes the user has not
>> required. See DIRSERVER-1719 for more explaination on this subject. Note
>> that the filtering of attributes represent around 9% of the global CPU time.
>> o getting back the ID from a Dn is a very costly operation (19% of the
>> global CPU time), and the longer the DN, the longer the operation. For each
>> RDN, we have to do a lookup in the RdnIndex. The only solution would be to
>> have a Dn ->  ID cache somewhere. This would boost the server performance,
>> that's for sure.
>> o fetching an entry from the backend cost 38% of the global time, out of
>> which 29% represent the cost to clone the entry. If we could avoid doing
>> this clone (see upper), we may have some major performances increase.
>> o when evaluating an entry to see if it fits the filter, we use the
>> reverseIndex, which is also a costly operation. We shoudl re-evaluate if it
>> wouldn't be better to use the MatchingRules comparator to do that instead
>> (reverse lookups account for 4% of the used CPU time)
>>
>>
> I guess we have these in JIRA?
No, not all of them. I will add the missing one (reverseIndex evaluation)


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Mime
View raw message