On this Tecra M5, OpenDS and Directory Server now sit side by side. So I built a 100K entries with make-ldif delivered as part of the OpenDS distro, and imported those entries into both servers.
Directory Server lets me import with dsadm import .... No sweat.
Curiously, OpenDS balked until I gave it more memory with OPENDS_JAVA_ARGS="-Xms512" preceding the import command. After that OpenDS imported the entries. The default heap is a bit too small for the current import implementation, I think, unless you are importing only a small sample.
I therefore also gave OpenDS 256M to work with, applying the suggestion about server startup size in the config/java.properties file with dsjavaproperties.
On this laptop, Directory Server is setup to listen on port 1389, OpenDS on port 2389. For the following searchrate runs, I started each server before the run, then stopped the server after the run. See how steadily Directory Server handles the load, whereas OpenDS warms up from a fairly slow start then gains the edge in terms of max. search rate?
~/dsrk6/bin$ ./searchrate -p 1389 -s base -b dc=example,dc=com -K -f "(cn=%s*)" \ -t 20 -A cn -i example_files/first.names Avg r=3602.65/thr (14410.60/sec), total= 72053 Avg r=3642.05/thr (14568.20/sec), total= 72841 Avg r=3619.45/thr (14477.80/sec), total= 72389 Avg r=3623.50/thr (14494.00/sec), total= 72470 Avg r=3641.45/thr (14565.80/sec), total= 72829 Avg r=3642.20/thr (14568.80/sec), total= 72844 Avg r=3608.35/thr (14433.40/sec), total= 72167 Avg r=3636.35/thr (14545.40/sec), total= 72727 Avg r=3635.70/thr (14542.80/sec), total= 72714 Avg r=3621.95/thr (14487.80/sec), total= 72439 Avg r=3622.25/thr (14489.00/sec), total= 72445 ^C ~/dsrk6/bin$ ./searchrate -p 2389 -s base -b dc=example,dc=com -K -f "(cn=%s*)" \ -t 20 -A cn -i example_files/first.names Avg r= 744.05/thr (2976.20/sec), total= 14881 Avg r=2465.85/thr (9863.40/sec), total= 49317 Avg r=3717.70/thr (14870.80/sec), total= 74354 Avg r=3577.90/thr (14311.60/sec), total= 71558 Avg r=3662.80/thr (14651.20/sec), total= 73256 Avg r=3606.50/thr (14426.00/sec), total= 72130 Avg r=3723.70/thr (14894.80/sec), total= 74474 Avg r=3721.85/thr (14887.40/sec), total= 74437 Avg r=3727.25/thr (14909.00/sec), total= 74545 Avg r=3690.20/thr (14760.80/sec), total= 73804 Avg r=3632.15/thr (14528.60/sec), total= 72643 ^C
Seems like if our servers can do pretty well on a laptop with the default config or just a few megs of memory, they really ought to be able to perform given appropriate server hardware and some tuning.
Hello Mark,
The 2 top speeds look suspiciously similar... This could be caused by the load generator (the searchrate process) being unable to generate enough load for the servers. If this is the case, what is indicated would then be the maximum rate of searchrate, not of the servers.
It might be interesting, as a check, to run searchrate from another, dedicated, fast machine...
Posted by Marc Kossa on February 18, 2008 at 06:12 PM CET #
Good point. We saw the LDAP modify rate appear the same when the disk we were using turned out to be the bottleneck.
Anyway, if my office gets too cold, I can run that searchrate job. The fan on the laptop was at full speed the whole time ;-)
Posted by Mark on February 18, 2008 at 06:22 PM CET #
Directory servers tend to be pretty fast at handling searches that don't match anything.
Posted by 24.242.137.147 on February 19, 2008 at 07:03 PM CET #