Le 5/1/12 3:05 PM, Alex Karasulu a écrit :
On Tue, May 1, 2012 at 4:08 AM, Emmanuel Lécharny<[email protected]>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
