<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 08/05/2015 02:31 PM, ghiureai wrote:<br>
</div>
<blockquote cite="mid:55C25691.1060906@nrc-cnrc.gc.ca" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<h1><font color="#000099"> <small><small>Mark, would be accepted
to accommodate only substring indexes followed by wild
char than ?<br>
aka :cn=abc*, <br>
cn=efg* .... may need couple of this indexes.<br>
</small></small></font></h1>
</blockquote>
<font color="#000099">in fact cn=ab* is fine as this is translated
to the key "^ab"</font>, but if you use two surrounding wildcards
then you must use 3 characters: cn=*abc*<br>
<br>
Regards,<br>
Mark<br>
<blockquote cite="mid:55C25691.1060906@nrc-cnrc.gc.ca" type="cite">
<h1><font color="#000099"><small><small> <br>
Thank you</small></small></font></h1>
<h1>[389-users] 389-DS poor performance retrieving groups</h1>
<pre>On 08/05/2015 08:24 AM, Mark Reynolds wrote:
><i>
</i>><i>
</i>><i> On 08/04/2015 11:57 AM, ghiureai wrote:
</i>>><i> <<a moz-do-not-send="true" href="https://www.flowdock.com/app/canfar/access-control/threads/QyygOboGumgx3qw3tIO_828AMgQ">https://www.flowdock.com/app/canfar/access-control/threads/QyygOboGumgx3qw3tIO_828AMgQ</a>>
</i>>><i>
</i>>><i> We are seeing poor performance from LDAP retrieving 2500-4500 entries
</i>>><i> compare with one of our regular RDBMS , here is bellow the result for
</i>>><i> a ldapsearch.
</i>>><i> We are questioning if for general cn=(.*..) search string , LDAP has
</i>>><i> to run a round trip for each subset result entry ?
</i>>><i>
</i>>><i> What cfg needs tuned to see some performance improvements beside
</i>>><i> cache mem size ?
</i>>><i>
</i>>><i> ldapsearch -x -s one -H -b 'ou=Groups,ou=ds,dc=cxxx,dc=net' -W -D
</i>>><i> 'uid=xx,ou=Users,ou=ds,dc=cxxxr,dc=net' 'cn=*MT*' 'cn, nsaccountlock'
</i>><i> Okay so this is probably unindexed, and the requested access log
</i>><i> snipet will confirm this. If you see notes=U or notes=A then we can
</i>><i> tune the id scan limit for that search:
</i>><i>
</i>><i>
</i>><i> Assuming this is the only search that is giving you issues:
</i>><i>
</i>><i> Example:
</i>><i>
</i>><i>
</i>><i> # ldapmodify <fill in the required parameters>
</i>><i> |dn: cn=cn,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config
</i>><i> changetype: modify
</i>><i> add:|||nsIndexIDListScanLimit|
</i>><i> nsIndexIDListScanLimit: limit=-1 type=sub values=*mt,mt*
</i>><i>
</i>><i>
</i>><i>
</i>><i> If there are other substring searches around the "cn" attribute you are having issues with, you can modify this to be:
</i>><i>
</i>><i> |# ldapmodify <fill in the required parameters>
</i>><i>
</i>><i> |dn: cn=cn,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config
</i>><i> changetype: modify
</i>><i> add:|||nsIndexIDListScanLimit|
</i>><i> nsIndexIDListScanLimit: limit=-1 type=sub|
</i>I'm on a roll today :-( sorry so this is not going to solve the issue.
There is no way to index or improve this type of search filter's
performance (cn=*mt*). If this is a reoccurring search filter, and your
client can be adjusted to use vlv indexes, then that might be option.
See the admin guide for more info on VLV searches/indexes.
Regards,
Mark
><i>
</i>></pre>
<p><br>
</p>
<br>
</blockquote>
<br>
</body>
</html>