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<[email protected]>wrote:
Le 4/12/12 12:39 AM, Alex Karasulu a écrit :
On Wed, Apr 11, 2012 at 5:55 PM, Emmanuel Lécharny<[email protected]>**
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
