Search operation : some more speedup

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

this morning, I was able to get an extra 3500 search/s on the 
coreSession.search() operation : up to 21798 search request per second 
from 18316 req/s yesterday.

This is a 2.8 times improvement since I started playing with Yourkit !

The same test done including the network layer (client + server) gives 
3763 search per second. Considering that I'm just searching for a single 
entry from its DN, with one single thread, I would be curious to know 
what kind of numbers we can get with external injectors pounding the 
server...

There are more to come, but it will be a bit more difficult. The three 
things we can improve are :
- Avoid normalizing twice the same DN
- try to use a DN cache to avoid costly parsings
- try to avoid cloning the entry before returning it (this is probably 
the major improvement, as cloning represents almost 40% of the consumed 
time)

I will try to work on the first and third aspects, as they are easier to 
implement.

More to come ...

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

Re: Search operation : some more speedup

[Alex Karasulu <ak...@apache.org>]

Whhooooooooaaaaahhhhh!!!! That's great man!

On Sat, May 8, 2010 at 12:13 PM, Emmanuel Lecharny <el...@gmail.com>wrote:

> Hi guys,
>
> this morning, I was able to get an extra 3500 search/s on the
> coreSession.search() operation : up to 21798 search request per second from
> 18316 req/s yesterday.
>
> This is a 2.8 times improvement since I started playing with Yourkit !
>
> The same test done including the network layer (client + server) gives 3763
> search per second. Considering that I'm just searching for a single entry
> from its DN, with one single thread, I would be curious to know what kind of
> numbers we can get with external injectors pounding the server...
>
> There are more to come, but it will be a bit more difficult. The three
> things we can improve are :
> - Avoid normalizing twice the same DN
> - try to use a DN cache to avoid costly parsings
> - try to avoid cloning the entry before returning it (this is probably the
> major improvement, as cloning represents almost 40% of the consumed time)
>
> I will try to work on the first and third aspects, as they are easier to
> implement.
>
> More to come ...
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.nextury.com
>
>
>


-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu