I found following events in access log, Is it resulting in etime > 10 milli sec(recomended).? Do we need to avoid VLV involved searches, if yes how can we resist the client to do so. Please help me.
[08/Oct/2012:09:22:31 +0000] conn=15860523 op=2 msgId=168 - SRCH base="ou=groups,dc=xxx,dc=com" scope=2 filter="(&(objectClass=groupofuniquenames)(uniqueMember=uid=xxxx,ou=people,dc=xxx,dc=com))" attrs="cn cn mail objectClass dn name objectsid"
[08/Oct/2012:09:22:32 +0000] conn=15860523 op=2 msgId=168 - SORT cn (31)
[08/Oct/2012:09:22:32 +0000] conn=15860523 op=2 msgId=168 - VLV 0:21474899:0:0 1:31 (0)
[08/Oct/2012:09:22:33 +0000] conn=15860523 op=2 msgId=168 - RESULT err=0 tag=101 nentries=27 etime=1.514740* notes=U
Thank in advance.
The client is sending the SORT control. The only really clean way to stop this behavior is to get the client to stop sending that control. Since the filter contains an individual user DN, creating a VLV index to support it seems impractical. You can disallow the use of the SORT control for this client if they are using a BIND account other than Directory Manager, but that's going to result in errors on the client side, and potentially a bad user experience.
Hi Chris, thank you very much for your response.
Could you please tell, how can we disallow SORT control from the client and can i have any guide for VLV index?
You can disallow the use of the SORT control for this client if they are using a BIND account other than Directory Manager, but that's going to result in errors on the client side, and potentially a bad user experience.
Well first you have to see whether the client is authenticating as Directory Manager. If that's the case you can't prevent it from using the control, you have to make it use a different login.
I don't currently have an installation of DSEE to check this on, but you should be able to find the VLV "feature" object somewhere under cn=config, either by searching against the suffix live, or by grepping in dse.ldif. The SORT control oids are 1.2.840.113556.1.4.*
I usually had to work with this in the opposite context, where a non-privileged account was trying to use the control but did not have permission to. So in that case we would add an ACI under there to give the user access to the feature. In this case, you would do the opposite.
The VLV index option is not practical. Since the filter must be part of the index definition, you would need an individual index for every user that would be queried like this.
When I look at the nentries (27) and the response time (1 sec) I wonder if this is that big a deal. Requesting the server to SORT the results might be worth waiting a second for it, though I agree it a bit long to wait. The usual policy is not to worry about little SORT queries like this.
I wonder if this is caused by general slowness in your service. Are other queries slow at the time this kind of response time is happening? Are these SORT type queries always slow or only sometimes? What is the CPU utilization like on the system? The SORT should really just be using a bit of extra CPU.