directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Problem with indexes...
Date Sat, 17 May 2014 07:00:14 GMT
Le 17/05/2014 06:40, Mark D a écrit :
> Emmanuel, thanks for the detailed information.  Kiran also had some feedback.
> The build I am using from trunk seems to be working much better.  There was serious 
> issue with previous build as the method I am using for indexes resulted in searches 
> completely failing which obviously breaks everything trying to use it. 

It's probably time for a new release...
>  The Mavibot update sounds like an exciting change.
Indeed. But it's way more complex that we initially thought it could be,
considering we are doing that on our spare time. At this point, we are
doing progress (and periodic mails are sent to the dev mailing list to
give some status), and it would be extremelly useful to get some
feedback on what we are doing (just because we are likely to make
mistakes, or chose the wrong path...). Checking the existing code would
be as useful.
> On the issue of speed, I am using a pool with ldap API 22 release and
> my searches are taking 7-13 msec.  
Ar you mesuring one search using System.currentTimeMillis()? Because on
most of the machines, the accuracy of this method is around 10ms (ie,
something that will take sub-ms time will be mesured as taking 10 ms, no
matter what. $

The best way to mesure the time that takes a request would be to use
nanoTime() instead.

> Seems long for single entry result sets,
> granted I have a lot of logging turned on so I can see internals working.

Yes, it's long, and probably you have to consider the network latency,
if you are going through the network. FTR, we have done some benchmarks
last year, with a MacBook Pro as a server (a 2012 MBP), and 5 injectors,
over a 100Mbs network. We were able to sustain a load of 13 000 search
request per second on a 10 000 entries database (random searches,
returning one entry), and the server was peaking at 70% CPU only.

Now, it depends on many parameters, like the network, the disk used in
the server, the memory you have, the number of entries, the log level...

View raw message