Does access log entry contains VLV results in high etime?

Question

Hello all,
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.
sumant.

Answer 1

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.