directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-629) Improve performance for search requests
Date Fri, 02 Jun 2006 06:56:30 GMT
    [ ] 

Emmanuel Lecharny commented on DIRSERVER-629:

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

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

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

The question now is : should we store a DN as an object (with RDNs, attribute 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 two DN are equals
(because their HashCode are equals), then we can do a String comparison of their normalized
form to insure that they are reallly equal.

Just some thought ...

> Improve performance for search requests
> ---------------------------------------
>          Key: DIRSERVER-629
>          URL:
>      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 entries. 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 entries
which DN are all parsed (cf attached log). The parser is synchronized and takes around 0,5
ms to parse a DN, and the entries to be parse are 100 (cf attached log again), 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:
For more information on JIRA, see:

View raw message