Hello Ando,
Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
Due to a real time scheduler I was expecting the results to be vice
Dieter,
I don't know how much this could be of any help, but today I tried to run a simple test using OpenLDAP 2.3.28 running on Linux 2.6.17 with RTAI, compared to the stock 2.3.6.15 kernel f the distribution used on that PC. I created a database with ~10000 users, fully indexed and fully cacheable (cachesize 10000). What I found (strange enough) is that the execution time of ldapsearch would differ a lot on the two systems, but sort of the reverse of what you experienced. I checked few cases:
- entry not yet in cache vs. entry already in cache
- system unloaded vs. system heavily loaded
in the case of RTAI, I also considered some hard real-time load, which gets the highest priority and accurate scheduling.
- searching for an entry not in cache, w/ RTAI, requires a little bit
longer than w/o RTAI; this requires access to disk; but
- searching for the same entry, after it's in cache, requires ~0.008s
w/ RTAI, and ~0.080s w/o RTAI (ten times longer! It's a slightly different kernel, but running on exactly the same machine, so, without too much investigation, I have no clue about the exact reason)
- under load (repeated disk and network access), the above entry in
cache times are occasionally delayed, but not that much, on both systems. w/ RTAI the average goes to ~0.010s, with peaks to ~0.020s; w/o RTAI no significant extra delay is added to the ~0.080s. The latter case makes sense, since the system already appears significantly delayed.
- under hard RT load (30% of one CPU, and 15% of the other CPU on a
dual CPU system), performances drop significantly; occasionally, the response time for not-in-cache entry, which requires access to disk, may raise to ~0.500s, with an average above ~0.100s. The response time when the entry is in cache is not significantly worse than in the case with non-RT load, ~0.020s.
This seems to indicate that with a (possibly) different hard RT scheduling there is no significant impact on basic OpenLDAP's slapd performances, so its design seems to have no impact on its execution in conjunction with RT schedulers. I have no clue, right now, about how the two RT systems compare.
I would like to acknowledge the support of Paolo Mantegazza, the main developer of RTAI, in performing those tests with a devel snapshot (called "magma") of that system; it should not differ from recent releases (3.4) in terms of scheduling policies and related issues.
Thank you for your test and report and thanks to Paolo Mantegazza. I think I have to dive a bit more into Montavista scheduler and have a chat with their support.
-Dieter