0

I'm running a pretty simple query to get back items using List.GetItems and it seems to be performing horribly on some of my sites (differing site collections). The lists being queried are essentially the same except for actual content. The number of items in the lists are about the same and the items that should be returned are about the same. Something to note, while there are 20k or so queries per site, the results are actually always the same, no item is returned- so there is no additional processing in this code, only the querying -- so what's being returned from the query isn't relevant I think.

In some sites it performs about 20,000 queries on a list in 1-2 minutes while in others it takes about 30 minutes. I created a powershell script that performs this functionality for logging and testing and I get the same performance results.

I am leaning towards this being a site related issue, i.e. a permission issue or something like that.

What kind of logging in powershell would be suggested to help figure out why site X is taking 30 minutes?

IIRC with SPServices, when you get items from a list there is a dependency on the default view. If you are expecting FIELD_X to be returned and FIELD_X isn't in the default view, it isn't returned etc. Similar issues could come from foldering, grouping, etc. Is this something that is also of concern with SP OM querying that is resulting in performance variances?

1 Answer 1

1

I'm not sure if this is possible from Powershell but what I would recommend is creating a webpart or page with your query, then wrapping your code in SPMonitoredScope. You could then enable the Developer Dashboard and get a much better idea of where the strain is.

Here's a blog post that explains the process: http://zimmergren.net/technical/sp-2010-developing-for-performance-part-2-spmonitoredscope

You may also want to download a tool to view the ULS logs while the page is running to see if any major errors are being thrown: http://archive.msdn.microsoft.com/ULSViewer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.