Hello list,
I have the following rules in /etc/openldap/slapd.conf for about 250 users (cust1 -> cust250).
This is an extract for user 'cust22' and user 'cust23' :
access to dn.regex="ou=tbook[12345],ou=contacten,ou=cust22,dc=mydomain" attrs=children by group.exact="cn=admins,ou=cust22,dc=mydomain" write by * none break
access to dn.one="ou=tbook1,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook2,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook3,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook4,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook5,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.regex="ou=tbook[12345],ou=contacten,ou=cust23,dc=mydomain" attrs=children by group.exact="cn=admins,ou=cust23,dc=mydomain" write by * none break
access to dn.one="ou=tbook1,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook2,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook3,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook4,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook5,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=cust23,dc=mydomain" read
I notice that there is a huge lack of performance (slow response times) when over about 100 users. There are quite some access rules in slapd.conf at that time.
There is about 8 seconds between query and response :
Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 fd=13 ACCEPT from IP=xx.xx.xx.xx:1046 (IP=0.0.0.0:389) Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" method=128 Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" mech=SIMPLE ssf=0 Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 RESULT tag=97 err=0 text= Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=1 SRCH base="dc=mydomain" scope=2 deref=0 filter="(&(telephoneNumber=*)(sn=t*))" Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=1 SRCH attr=cn sn telephoneNumber
Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=2 ABANDON msg=2 Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=3 UNBIND Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 fd=13 closed
Question : how can I get a better performance ? How can I adapt my access rules for better performance ?
Thanks !
Kind Regards,
Jonas.
--On Thursday, September 04, 2014 10:10 AM +0200 Jonas Kellens jonas.kellens@telenet.be wrote:
Hello list,
I notice that there is a huge lack of performance (slow response times) when over about 100 users. There are quite some access rules in slapd.conf at that time.
There is about 8 seconds between query and response :
Question : how can I get a better performance ? How can I adapt my access rules for better performance ?
Start with providing useful information:
What openldap version are you running? Which openldap backend are you using? Have you correctly indexed the attributes being used to filter on?
I would also note that if you are going to do something like sn=t*, you may need to play with the index lengths for substrings, as documented in the manual page. IIRC, they default to triplets.
etc.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hello,
Any more feedback on this ?
It seems that when there is a query with filter "telephoneNumber" and a search for "cn sn" the search goes faster (no delay between query and answer) :
Sep 22 11:12:41 slap01 slapd[22668]: conn=3580 fd=13 ACCEPT from IP=my.pub.ip..add:54994 (IP=0.0.0.0:389) Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" method=128 Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" mech=SIMPLE ssf=0 Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 op=0 RESULT tag=97 err=0 text= Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 op=1 SRCH base="dc=mydomain" scope=2 deref=0 filter="(&(telephoneNumber=70470470*)(sn=*))" Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 op=1 SRCH attr=cn sn telephoneNumber Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 op=2 UNBIND Sep 22 11:12:42 slap01 slapd[22668]: conn=3580 fd=13 closed
So how can I get the same speed (with no delay) when filter is "sn" ?
Thank you.
Jonas.
On 04-09-14 09:10, Jonas Kellens wrote:
Hello list,
I have the following rules in /etc/openldap/slapd.conf for about 250 users (cust1 -> cust250).
This is an extract for user 'cust22' and user 'cust23' :
access to dn.regex="ou=tbook[12345],ou=contacten,ou=cust22,dc=mydomain" attrs=children by group.exact="cn=admins,ou=cust22,dc=mydomain" write by * none break
access to dn.one="ou=tbook1,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook2,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook3,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook4,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.one="ou=tbook5,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=cust22,dc=mydomain" read
access to dn.regex="ou=tbook[12345],ou=contacten,ou=cust23,dc=mydomain" attrs=children by group.exact="cn=admins,ou=cust23,dc=mydomain" write by * none break
access to dn.one="ou=tbook1,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook2,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook3,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook4,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=cust23,dc=mydomain" read
access to dn.one="ou=tbook5,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=cust23,dc=mydomain" read
I notice that there is a huge lack of performance (slow response times) when over about 100 users. There are quite some access rules in slapd.conf at that time.
There is about 8 seconds between query and response :
Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 fd=13 ACCEPT from IP=xx.xx.xx.xx:1046 (IP=0.0.0.0:389) Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" method=128 Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" mech=SIMPLE ssf=0 Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 RESULT tag=97 err=0 text= Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=1 SRCH base="dc=mydomain" scope=2 deref=0 filter="(&(telephoneNumber=*)(sn=t*))" Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=1 SRCH attr=cn sn telephoneNumber
Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=2 ABANDON msg=2 Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=3 UNBIND Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 fd=13 closed
Question : how can I get a better performance ? How can I adapt my access rules for better performance ?
Thanks !
Kind Regards,
Jonas.
Jonas Kellens wrote:
It seems that when there is a query with filter "telephoneNumber" and a search for "cn sn" the search goes faster (no delay between query and answer) : [..] So how can I get the same speed (with no delay) when filter is "sn" ?
I'd first check indexing configuration.
Ciao, Michael.
On 29-09-14 17:00, Michael Ströder wrote:
Jonas Kellens wrote:
It seems that when there is a query with filter "telephoneNumber" and a search for "cn sn" the search goes faster (no delay between query and answer) : [..] So how can I get the same speed (with no delay) when filter is "sn" ?
I'd first check indexing configuration.
Ciao, Michael.
Hello,
thank you for your answer.
My indexes are as follow :
# Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index telephoneNumber eq,pres,sub
I have tried reducing this to the following, but the performance stays the same :
# Indices to maintain for this database index objectClass eq,pres index ou,cn,sn,telephoneNumber eq,pres,sub
And yes, I did the slapindex :
[root@slap admin]# slapindex -f slapd.conf -b "dc=mydomain" cn sn telephoneNumber
Help is appreciated.
Kind regards,
Jonas.
Jonas Kellens wrote:
On 29-09-14 17:00, Michael Ströder wrote:
I'd first check indexing configuration.
I have tried reducing this to the following, but the performance stays the same :
# Indices to maintain for this database index objectClass eq,pres index ou,cn,sn,telephoneNumber eq,pres,sub
Then I'd recommend to check whether your configured ACLs are really causing the bad performance.
Ciao, Michael.
Michael Ströder wrote:
Jonas Kellens wrote:
On 29-09-14 17:00, Michael Ströder wrote:
I'd first check indexing configuration.
I have tried reducing this to the following, but the performance stays the same :
# Indices to maintain for this database index objectClass eq,pres index ou,cn,sn,telephoneNumber eq,pres,sub
Then I'd recommend to check whether your configured ACLs are really causing the bad performance.
Remember that by default, a substring index only works for substrings of 3-4 characters long, minimum. So searching for (sn=t*) will not use the index unless you change the index minimum length and reindex the DB.
--On Tuesday, September 30, 2014 5:15 PM +0100 Howard Chu hyc@symas.com wrote:
Michael Ströder wrote:
Jonas Kellens wrote:
On 29-09-14 17:00, Michael Ströder wrote:
I'd first check indexing configuration.
I have tried reducing this to the following, but the performance stays the same :
# Indices to maintain for this database index objectClass eq,pres index ou,cn,sn,telephoneNumber eq,pres,sub
Then I'd recommend to check whether your configured ACLs are really causing the bad performance.
Remember that by default, a substring index only works for substrings of 3-4 characters long, minimum. So searching for (sn=t*) will not use the index unless you change the index minimum length and reindex the DB.
Which I noted in this thread already on September 4th.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 30-09-14 17:15, Howard Chu wrote:
Michael Ströder wrote:
Jonas Kellens wrote:
On 29-09-14 17:00, Michael Ströder wrote:
I'd first check indexing configuration.
I have tried reducing this to the following, but the performance stays the same :
# Indices to maintain for this database index objectClass eq,pres index ou,cn,sn,telephoneNumber eq,pres,sub
Then I'd recommend to check whether your configured ACLs are really causing the bad performance.
Remember that by default, a substring index only works for substrings of 3-4 characters long, minimum. So searching for (sn=t*) will not use the index unless you change the index minimum length and reindex the DB.
Hello Howard,
can you tell me where I can change the index minimum length or point me to the right documentation ?
Searching for "openldap index length" on google does not give much usefull results.
I can only find info on set_cachesize in the DB_CONFIG file.
Kind regards,
Jonas.
On 02-10-14 16:30, Michael Ströder wrote:
Jonas Kellens wrote:
can you tell me where I can change the index minimum length or point me to the right documentation ?
See directives index_substr_*_minlen in slapd.conf(5)
or
attributes olcIndexSubstr*len in slapd-config(5)
Ciao, Michael.
Thank you for pointing me to the right information.
I have -however- an extra question.
The man file states :
index_substr_if_minlen <integer> Specify the minimum length for subinitial and subfinal indices. An attribute value must have at least this many characters in order to be processed by the indexing functions. The default is 2.
If the default is 2 (as mentioned in the documentation), then why does every look-up takes very long even with 2 characters in the search string ??
The look-up speeds up when there are at minimum 4 characters used in the search string. When using 1, 2 or 3 characters the search is very slow.
Are you sure this is the correct parameter to edit ?
Kind regards,
Jonas.
openldap-technical@openldap.org
-
Howard Chu -
Jonas Kellens -
Michael Ströder -
Quanah Gibson-Mount