directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Some more info about the base search operation
Date Fri, 07 May 2010 07:40:45 GMT
Emmanuel, that's an excellent analysis technique with the internal probe.
Looking forward to seeing more data on this.

I'm also interested in seeing what the results are for the other operations.
We've always focused on design but design for efficiency without doing any
serious optimizations. I really think this server can be blazing fast if we
gave it the time.


On Thu, May 6, 2010 at 11:42 AM, Emmanuel Lecharny <>wrote:

> Hi guys,
> I have added a Timer interceptor at two places in the chain to measure the
> time consummed in the backend and in the full chain. I got some interesting
> results :
> - A search does a lookup
> - A lookup costs 62 micro second on the backend, 85 microseconds when
> traversing the full chain
> - A search costs 24 microseconds on the backend, 102 microseconds when
> traversing the full chain
> - it takes 35.563 seconds to do 100 000 searches, so a single search costs
> If we consider that a search does a lookup, we should have something around
> 85 + 24 = 109 microseconds for a global search instead of 102 microseconds,
> but the timing accuracy may be the cause for such a difference.
> Anyway, that mean we can do around 9200 search request per second on the
> server, not including the network layer (request encoding + decoding,
> response encoding + decoding), which adds an extra 245 microseconds to the
> server's delay (it costs 355 microseconds to do a search through the
> network).
> At this point, as we measure the full time on the client side, we can't
> determinate the number of search per second the server can provide, but it's
> definitively something between 9000 and 2800 per seconds, considering that
> the server has to decode the request and encode the response.
> What we now have to analyze is the reason why we do a lookup for each
> search request, as if we can spare this call, we may perfectly divide the
> processing time by two, and also see where we can speedup the server.
> More to come later.
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message