[ http://issues.apache.org/jira/brows...241
4364 ]

Emmanuel Lecharny commented on DIRSERVER-629:
---------------------------------------------

After having profiled the server (10 random search request), I saw that DnPa
rser is responsible for 90% of the CPU usage (10 808 ms / 12 124 ms).

Almost all those DnParse calls (893) are done in the DnComparator.compare() 
method, which was already optimized months ago.

We parse DN before compare them becazuse we want to be sure that they are no
rmalized when we compare them. Obviously, this is overkilling, because the D
N should already have been normalized on the upper layer, so n the backend, 
we should have stored a nor
malized form of the DN (and of couse the user provided DN, too), so this par
sing should not be necessary.

The question now is : should we store a DN as an object (with RDNs, attribut
e and values), or as a String? The advantage of stroring a tree is that the 
comparison is very fast, but we may also need to store the serialized object
.

We could also store an integer representing the hashcode of the dn, and if t
wo DN are equals (because their HashCode are equals), then we can do a Strin
g comparison of their normalized form to insure that they are reallly equal.

Just some thought ...

> Improve performance for search requests
> ---------------------------------------
>
>          Key: DIRSERVER-629
>          URL: http://issues.apache.org/jira/browse/DIRSERVER-629
>      Project: Directory ApacheDS
>         Type: Improvement

>     Versions: 1.0-RC3
>     Reporter: Emmanuel Lecharny
>     Priority: Critical
>      Fix For: 1.0-RC4
>  Attachments: apacheds-SEARCH.log
>
> Search requests are pathological long when the server is loaded with entri
es. I have a server with 10000 entries, and I do a search for a random user.
 It takes around 50 ms to find the user (20 searches per second, maximum).
> This is due to the fact that, when we have a lot of entries, the search look for e
ntries which DN are all parsed (cf attached log). The parser is synchronized and tak
es around 0,5 ms to parse a DN, and the entries to be parse are 100 (cf attached log
 ag
ain), so the 50 ms are spent parsing, parsing and parsing ...

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]