Searching OpenDS and Directory Server on OpenSolaris

Download DSEE free of charge Download OpenDS

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.

Comments:

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 10:12 AM 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 10:22 AM CET #

Directory servers tend to be pretty fast at handling searches that don't match anything.

Posted by guest on February 19, 2008 at 11:03 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Mark Craig writes about Directory Services products and technologies. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today