You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2008/03/08 03:10:42 UTC
Some more numbers...
Two weeks ago, I run my own favorite micro-benchmark on my laptop,
reaching 3170 random search req/s on a 10K entries base.
After some cleaning, I'm no up to 4070 req/s. No too bad...
Just in case, the best result I got was 4800 req/s with 1.5.0 running on
the JRockit JVM.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Some more numbers, (2)...
Posted by Emmanuel Lecharny <el...@gmail.com>.
Emmanuel Lecharny wrote:
> Two weeks ago, I run my own favorite micro-benchmark on my laptop,
> reaching 3170 random search req/s on a 10K entries base.
>
> After some cleaning, I'm no up to 4070 req/s. No too bad...
But we can do much better !
Here is where we can have some major gains :
1) Attributes <-> ServerEntry conversions : 31.93% of the whole time.
2) lookup() for collectiveAttribute attribute : 19,70% of the while time
3) LdapDn constuctor when fetching data from the backend, plus
normalization : 16,5% of the whole time
(1) will be removed when we will be able to store ServerEntries in the
backend (expected soon)
(3) will be solved when (1) will be, as we will store normalized forms
of DN into the serialized ServerEntry
(2) is much more an optimization. We currently filter the returned
attributes in the search engine, and we are looking for some specific
attributes later (like the "collectiveAttributeSubentries" attribute).
If we fetch the whole entry, and remove the attributes which were not
requested later, we could avoid this very expensive lookup operation.
I do expect to gain at least of factor of 2 if we implement those
optimization, may be more (2.9 ? This is what I get if I use the row
numbers). That would result in more than 10000 req/s... cross your
fingers !!!
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org