directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Fwd: Re: [Index] OneLevel index removal, performances
Date Thu, 12 Apr 2012 04:54:50 GMT
I think I dropped he ML in my initial response... Forwarded to it.


On Thu, Apr 12, 2012 at 1:45 AM, Emmanuel Lécharny<elecharny@gmail.com>wrote:

>  Le 4/12/12 12:39 AM, Alex Karasulu a écrit :
>
>   On Wed, Apr 11, 2012 at 5:55 PM, Emmanuel Lécharny<elecharny@gmail.com>**
>>  wrote:
>>
>>   Hi guys,
>>>
>>>  Kiran and I conducted some quick performance tests to compare the numbers
>>>  we get with the server with no OneLevel index compared to the trunk
>>>  before
>>>  the merge. It's quite interesting :
>>>
>>>  Operation (before/after) per second
>>>
>>>  Add : 222/264 (me) 649/746 (Kiran)
>>>  Delete : 156/191 (me) 442/544 (Kiran)
>>>  Search : 5215/5214 (me) 19932/20335 (Kiran)
>>>  Move : 308/303 (me)
>>>  Rename : 380/392 (me)
>>>  MoveAndRename : 204/275 (me)
>>>
>>>
>>>   What exactly do these numbers correspond to? Is this a single operation
>>  or
>>  are they averages? Also I see for your machine you have a number/number -
>>  what's this mean?
>>
>  Those are the number of averaged operations per second on trunk before the
>  OneLevelIndex removal, and after the removal. It's done with more than
>  10000 operations (15 000 adds/deletes, above 1 million searches)
>
>
>>
>>   My machine is an old Linux computer with an old CPU, Kiran has a quad
>>>  core
>>>  recent computer.
>>>
>>>
>>>   This definitely should mean your disadvantaged however there are other
>>  considerations besides just CPU like disk access speeds. However if your
>>  machine is much older it's feasible that it's disk is slower.
>>
>  All is in memory.
>
>
>>  It's best regardless to compare these operations on the same machine.
>>
>  We did the comparison on two different machines, each time comparing the
>  previous perfs with the new perfs.
>
>
>>
>>   The modifications are now around 20% faster (add/delete).
>>>
>>
>>  That's awesome but can you run it on the same hardware? That way it might
>>  actually be more.
>>
>  This is what we did.
>
>
OK I was not able to interpret this immediately sorry about it. Everything
makes sense now to me :).


>
>>
>>   The Move operation has been deeply modified and is not optimal in the new
>>>  operation. We can most certainly improve it.
>>>
>>>  The very nice point is that searches are not slowed down by the removal
>>>  of
>>>  the index.
>>>
>>>
>>>   I think we need more tests to confirm this if we're only performing a
>>  single search. There are several parameters to the search and if we're
>>  doing a single entry lookup we might not be seeing the impact fully.
>>
>
>  I was thinking about doing the same test with a one level scope on a
>  loaded server (100K entries). I will conduct such tests tomorrow.
>
>
I was wondering if the magnitude of the candidates returned results in
linear verses non-linear responses. Like for example you do a one level
search returning 500, 1000, 1500 ... up to say 15000 and what happens
performance degradation wise.


-- 
Best Regards,
-- Alex



Mime
View raw message