[Date Prev][Date Next]
Large "dynamic" groups and performance
- To: email@example.com
- Subject: Large "dynamic" groups and performance
- From: Al <firstname.lastname@example.org>
- Date: Tue, 5 Apr 2011 10:48:53 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=6TG6E2+5DW9VegHBUoJHV4Sjl7N1BfvitUB2S/BBAYI=; b=bMooL+YkVvkcap2LQjeeVQlONMyjp/PWYYK5DwZxu3P3XMjAedllXTBdoqcHGvFnr8 goze34WsSBiNL0MsFUzg1vLkw7iZKFRhdyDuHuZ0zrfdScSYL8O+4ydLBiRXrxHdXUmx dEyd+R1PBBWI2Z6+rN2KocqM74C5DNK9uwwGU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hjXva0HT0xL/CUYrny0LUcmd5+ul5M61GwUYXXMBvCC4qBHCtZDh0KL/TcvTXpxIO/ /rhI2hokGm/ImyKqkFrW/9HriJV2yoirwOBRQ04oAfykCv4SRu0RvXvy/39kGlcqhY5H dKXe+UvbGvXLjIJgPLuAY2khbT3QOrwyCkH9Q=
Hi All -
We are currently attempting to migrate from a commercial LDAP server to OpenLDAP. Luckily our data is pretty standard, and the migration itself will be simple. I am having issues with our groups that programatically have large numbers of adds and deletes done to its member list. This transaction happens when a user logs into our website (the login mechanism compares their current groups with what they should have (from an external DB query) and makes the necessary adjustments). Other applications then use these groups for permissions.
We are using the basic uniquemember within a groupOfUniqueNames. Uniquemember is indexed with equality. When the groups are small, performance is quite good - but once the groups begin growing, the adds and deletes of the members really starts suffering ( greater than 2 - 3 seconds per person). The reads still seem good. On our existing LDAP store, we see response times of less than a second for this same transaction. We have about 175 groups, that range in size from 10 members to 50,000 members. Most of the groups are around 1,000 members. I can go into more detail of the exact sizes if needed.
I have a very basic configuration right now for testing. I've messed around with different transaction log settings, different caching settings and even played with DB_TXN_NOSYNC. DB_TXN_NOSYNC definitely helped, but its still not great. Can anyone recommend any settings that might help me improve the performance?
Thanks in advance!
My environment and settings:
HP blade server, 8 cores @ 2.67Ghz, Redhat 5.3, OpenLDAP 2.4.25, Berkeley 5.1.25:
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
by self write
by users read
by anonymous auth
index objectClass eq
index uniquemember eq
index cn pres,eq,sub
set_cachesize 2 0 1