Monday, 29 October 2007

Don't Sort on the Server in Active Directory

This is just a reminder that you should not use server-side sorting with your queries in Active Directory or ADAM.  This situation was reinforced when a reader asked me why a particular ASQ (attribute scope query) was failing with an error when querying a rather large group (more than 20,000 members).  The customer was getting a fairly nondescript error, "The server does not support the requested critical extension" about halfway through his results.

After checking the network trace, and handing the DSID error back to my buddy Eric - we (more he, than me) determined it was failing in the code path for sorting.  It turns out that sorting this much data on the server requires temp table space.  If you run out of space before the sorting is complete you get this type of error.  This is not particular to ASQ by any means, but all sorting.

The moral of story is don't sort on the server.  This is a very real example of why this is the case.  You can always easily sort once you have results on the client.

Wednesday, 28 November 2007 10:11:14 (Eastern Standard Time, UTC-05:00)
Interesting post, it made me think:

- What about Simple Page Search Control? I mean when you do a paged search the results are stored waiting for further requests (the cookie thing) so I assume that it requires temp table space too. Do you know if that's true?

... and ...

- You could extend the recommendation to "Don't use Virtual List View Control whenever possible" because VLV has to be sent along with the Server Sort Control. In addition I have noticed that every time you request a page through VLV the server does the whole searching & sorting again, so I think this is even worst :-)

Unfortunately some servers (Sun One, for instance) doesn't support other paged searches mechanisms so VLV is the only option there.
Martin
Thursday, 29 November 2007 13:58:27 (Eastern Standard Time, UTC-05:00)
There might be some degree of temp table usage in a paged search, but a key difference is that it would not have to collect all results before sending them. It can collect a page, send it and move on. Typically, we have an index in this case, so we don't need to collect all results first.

As for the VLV, you do have to be careful. In ADAM, we can use it safely with a containerized index, but in AD we had a problem with the temp table usage. I believe this has been fixed in SP1 of 2003, but I would need to verify. The short story is, yes, there are certain use cases where a VLV can hit this issue if you don't have the right kind of index on your data (and you have lots of results).
Comments are closed.