Andreas Grabner About the Author

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi

SharePoint: Monitoring individual List usage and performance

We all know that SharePoint list performance can degrade the more items are stored in the lists and depending on how the lists are filtered when viewed. You will find many arcticles and blog entries talking about the 2000 items per list limit. The 2000 items however are not the real problem – you can in fact have much more items in the list. It all depends on how those lists are viewed. The question therefore is: How can we identify which lists have degraded in performance and how are they commonly used?

In order to do the correct performance correcting actions we first need to understand the current usage scenarios and analyse the resulting performance problems.

Scenario 6: Which are my slowest lists, how are they used and why are they slow?

There are multiple ways to figure out current access statistics of your SharePoint application. You can analyze IIS log files or you can make use of the SharePoint Usage Reporting Feature.

The easiest way monitor list performance is by analyzing the http response times to the respective SharePoint List and SharePoint View URLs. A SharePoint URLs has the following format: http://servername/site/{LISTNAME}/{VIEWNAME}.aspx. In order to analyze it we can group the requests based on those two indicators. I used dynaTrace’s Business Transaction Feature to group the captured PurePath’s according to a regular expression. Following images show the usage scenario of my lists and views:

Shows Individual List Performance and Usage counts

Shows Individual List Performance and Usage counts

Shows individual View Performance and Usage count

Shows individual View Performance and Usage count

These results give us a good indication about which lists and views are used more frequently and how well they perform.

Additionally to analyzing the HTTP Requests – which only provides accurate data for pages that display the specific list or view – we can analyze the list usage of custom web parts or custom pages that access more than just a single list or view or that access a list in a special filtered way.
We can do that by analyzing the interaction with the SharePoint object model like SPRequest.RenderViewAsHtml which is used to render lists and views or access to the SPList and SPView. The following illustration shows usage and performance metrics based on SPRequest method invocations:

Analyzing Performance and Usage through SharePoint Object Model

Analyzing Performance and Usage through SharePoint Object Model

The illustration above shows us the internal GUIDs of the Lists. Each list and view is uniquely identified with a GUID. There are different ways to find out the actual list name: You can paste the GUID in the URL to edit the settings of the list or view. Here is an example: http://servername/_layouts/listedit.aspx?List={GUID} (GUID must be URL-Encoded). The other option would be to open your content database and query the table AllLists. This table contains both the GUID and the List name.

Why are certain lists slower?

Now as we know which lists and views are accessed frequently we can focus on those that show bad signs of performance. In order to improve the end user experience we should focus on lists that are accessed very frequently rather than lists that are accessed just occasionally.

There can be multiple reasons why lists perform slow:

  • Too many items are displayed in the list view
  • Too many items in the list without using filters and indexed columns
  • Inefficient data access by custom web parts

I already covered list performance in my previous blog posts and therefore suggest that you check them out. I am also going to focus the next blog entries on indexed columns which will show you how indexing in SharePoint really works and what you want to consider when setting up indices.

Conclusion

Its important to understand which lists and views are accessed frequently and what the performance characteristics are. Knowing the usage patterns allows you to specifically focus on those lists and views that impact most of our end users.

Comments

  1. Interesting blog post Andreas. The graphs in your dynaTrace application look like a good way to visualize SharePoint performance.

  2. The interesting aspect about our approach is that we actually capture the data from within the application context. Therefore its possible to also track performance down to individual Web Parts that execute queries against SharePoint lists and views. Just analyzing URL-based performance is a good start – but in highly customized SharePoint applications you often dont just have a single list on your page using the Standard List View WebPart

    Great that you like our approach and our ability to also visualize the captured data. Keep looking on this blog. I have some additional blogs in the queue talking about indexed columns and I will also touch the topic memory – which is another important aspect with SharePoint deployments

  3. MAPILab provides a very good SharePoint usage reporting solution: MAPILab Statistics for SharePoint. Detailed reports on visitors, documents, lists, search, etc. You can try its free trial version, or look through the online demo: http://www.mapilab.com/sharepoint/statistics/.

  4. CardioLog is the leading analytics solution for SharePoint enterprises and portals. For a comparison between CardioLog and Sharepoint’s built-in reporting, please go here: http://www.intlock.com/intlocksite/ProductsAndServices/CardioLog/CardioLog-vs-SharePoint-Reports.asp.

    For any additional information on CardioLog, go to http://www.intlock.com.

  5. Ramkumar says:

    Your posts are very usefull for us. We have learnt so much from your articles…Thanks Lot!!!

Trackbacks

  1. [...] Performance, Scalabilty and Architecture – Java and .NET … [...]

Comments

*


5 + = fourteen