> Hi, > > The ldapsearch numbers are down below. Not all the numbers to all the > indexed attributes are there ... but all the "cachemiss" -numbers for > them were 0's. > > In the log there are not many "notes=U" lines but some "notes=A" > lines: > # grep "nentries=" access | grep -v "notes=" | wc -l > 65674 > # grep "nentries=" access | grep "notes=U" | wc -l > 173 > # grep "nentries=" access | grep "notes=A" | wc -l > 2189 I think these might be the most telling. notes=U means there was an unindexed component in the search. notes=A means that all components of the search were unindexed. I think you should examine these queries closely, look at what is and isn't indexed. Make sure the attributes have an equality syntax, and if they do, add them as an index. This will likely help you a lot. > > Still about the nsrole -attribute. We have index for nsroledn > attribute > but not for nsrole. I have thought that indexing nsrole-attribute is > not > reasonable and wouldn't improve search since it is a calculated > attribute. But is this so - should the nsrole-attribute be indexed as > well? It depends on the structure of your roles. You'll probably pick up the issues in the above exploration. > > The discussion if to use either groups and memberOf attributes or > roles > is valuable. However we have made the decision to use roles long ago > and > it would be a big effort to change the approach... > I'll leave that decision to you. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
