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...
