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
