On 12/03/2015 05:02 PM, William Brown wrote:
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.
"logvonv.pl -V <access logs>" will give you detailed info on those unindexed searches, but note that it will take a long time to run, and it will generate a lot of output.  I recommend redirecting the output to a file when using it.


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.



--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org