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.

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.

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 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.