directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Some more speed improvement for basic operations
Date Tue, 08 Jun 2010 06:14:52 GMT
On 6/8/10 1:18 AM, Quanah Gibson-Mount wrote:
> --On Tuesday, June 08, 2010 1:01 AM +0200 Emmanuel Lecharny 
> <elecharny@gmail.com> wrote:
>
>> Hi guys,
>>
>> today I finished to clean the rename() operation, and I just have the
>> three last operations remaining to be clean, ie move, moveAndRename and
>> compare.
>>
>> In the meantime, I was able to avoid an Entry clone to be done, and this
>> has a huge impact on some operations. Here are the result I get with or
>> without the clone :
>>
>> add    : 578/s(with) / 607/s (without) / +5%
>> lookup : 19 568/s(with) / 26 542/s (without) / +36%
>> search : 19 727/s(with) / 19 560/s (without) / ---
>> modify : 1 991/s(with) / 2103/s (without) / +5%
>> delete : 248/s(with) / 248/s (without) / ---
>>
>> As we can see, the lookup is really faster with such a modif. The other
>> operations aren't that much impacted, the cost of writing on disk kills
>> the gain we could have.
>>
>> One more thing : this is a test done with one single thread, directly on
>> top of the core-session.
>>
>> However, it demonstrates that with enough cache, and a good network
>> layer, we should be able to get some good performances out of the 
>> server.
>
> Exciting. :)  One of these days soon, I'll have a slamd perf lab again 
> (HW exists, waiting on installation), so I can draw up some numbers 
> between OpenLDAP, ApacheDS, and maybe some others.

We still have a long way to go to get numbers that compares to what we 
can get with OpenLDAP :)

However, we know where to squeeze performance out of the parts that need 
it :
- the network ayer that may be sub-optimal at this point,
- definitively the backend, as we have some serious contention when 
working with more than one client.

Considering using the server embedded, ie without dealing with the 
network layer, I must say I like the performance we now get :)

However, we are still cleaning the house at the moment, considering that 
having a stable, robust and compliant server is more important than 
having good performances. Right now, the fnny part of the on going work 
is that while working on making some operation atomic (we had some issue 
on ModDN operations), we get a side benefit of having better performance 
by removing useless processing.

Thanks Quanah !

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.nextury.com



Mime
View raw message