[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Performance Tuning

> Hi,
> We are doing some performance testing on our server which is connected to an
> openldap slapd.  In the testing program, we do the following operations for
> 100 times: query the ldap server, modify entries, delete the entries, and
> create them again.

Assuming n = 1000

1. Query n entries.
2. Modify all of those n entries in some way,
3. Delete all of those n entries.
4. Re-Add the same n entries.

Is this how the test is running?

LDAP is really not designed for constant change, so the following operations
are all usually very, very, slow:
1. Modification
2. Delete
3. Add

The following operation is usually very, very, fast:
1. Query (like a database select).

To reflect the design goals of LDAP, a performace test should be more
1. Add 1000 entries.
2. Query (lookup) each entry 300 times.
3. Modify 50 of those entries.
4. Run 2000 more queries on 500 of the entries.
5. Delete 20 entries, then add 20 entries.
6. Randomly query 500 entries 10 or more times.
7. Modify 50 entries.
8. Query all 1000 entries 5 times.

Notice that LDAP is not designed for records that change very often, it is
designed for very fast retrieval of the exact same records, over and over
again. Which doesn't completely exaplian your problem:

> The result is not very promising.  The query time is increased from 0.223
> second

This seems very, very, slow. (If this is for each record).

> to 3.038 second.  It will reduce to somewhere close to 0.223 if I
> delete the old database directory and add in the data again using ldif add.
> Is there anything we can do about it other than clean the database manually?

Possible causes:
a) modification tracking is on (All entries are now larger by 4 lines, until
b) replication is on (your replication deletions are still running, long after
the records have been been removed from the master?)
c) something else. :-)

What does your directory look like after the entries have been deleted, but
before maore have been addded? Are the indicies large? Do they grow after
each add/delete cycle? Are you using replication?


Personal:  ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/
Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my employers, or any of the other little voices in my head.