Sick platform

Performance issue: where to start?

– “What’s up doc?”
– “Nothing new really, what’s up SharePoint admin?”
– “Well, I got problems with my SharePoint farm. Years after years, it got slower and slower with now some intermittent down-times. It was not that bad until the end-users came back from spring holidays and just thought this was enough.”

– “Oh I see, this is a typical syndrome of the old farm disease.”
– “Is it serious doctor?”
– “Nothing to worry about, I’ll give a couple of recommendations and the beast will get better. Before I do that, let me explain a bit about what can impact performance in a SharePoint farm.”

SharePoint layers

The diagram below shows the relationships between the different components of a SharePoint farm and the notions of performance, cost, user experience…etc

This diagram can be applied for all sort of software but it is even truer in case of SharePoint as it is such a complex application which needs to be quite responsive at it is first a WEB application.

Performance, ease of exploitation, cost and disaster recovery possibilities are all impacted by:

  • The infrastructure which supports it: resources (RAM, CPU…etc) of physical or virtual servers. Performance of storage bay. Network (bandwidth, fabric interconnect between the virtual platform and the storage bay…etc). For example, a storage bay shared with other software with a need of high I/O may slow disk access of the SQL Server used on the SharePoint farm.The most demanded servers are usually the front-end servers and the SQL server(s).
    Run perfmon for a few hours to check the RAM and CPU usage on the front-end servers.Do the same for the SQL Server but check especially the Average disk queue length. If it’s over 15 ms, you may have a problem of disk access. More to come on how to optimise SQL Server for farms running in the long term.
  • The logical architecture: this is how the farm was designed. The choice over the number of servers and the SharePoint services executed on each of them. The number of service applications and their redundancy if needed (search service notably). E.g. the use of Workflow manager on a dedicated server over SharePoint 2010 workflow engine can improve performance as resource will be saved on the SharePoint front-end web servers.Checking which services run on which servers and change the configuration is quite easy to do. A good start to see if your configuration is right, is the “Services on server install worksheet” XLSX spreadsheet.
  • The functionalities, settings and usage: this is how the web application or site collections have been configured to meet needs. This is also how the platform is used. As we know, a platform with no end-users is soooo easy to support :-)Those have a great impact on user experience but may also have an effect on performance. Typical examples are: having a view displaying a lot of item in a list. Also a SharePoint 2010 workflow modifying lots of items in a huge list.A quick check of the number of SharePoint 2010 workflow instances running on a farm can pinpoint potential performance problem. The same goes with running a PowerShell script listing all the list going over, let’s say, 10000 items.
  •  Finally the developments and third party products: those are implemented when the standard functionalities of the SharePoint version don’t meet the customer’s needs. Typical examples are custom web part which slows the rendering of an intranet home page or the implementation of poorly written anti-virus application which inserts itself into the mechanics between the end-users and SharePoint when downloading or uploading documents.Looking at the source code of a WSP solution may take a lot of time and specific developer expertise is needed. Also, it may be difficult politically to point out a culprit development when the functionality is badly required by the project owner.The “Developer dashboard” is a great tool to spot potential performance problem: a quick check on how long each part of a page is taking to download can be done using Fiddler:

Governance and change management are also important factors in a SharePoint farm as those will impact, amongst other things, the overall user experience, the way the farm is maintained and thus the cost.

In conclusion, a performance audit should ideally cover all those 4 layers, however it may be hard to see what’s going on especially in the top layers.
My advice: depending on the expertise available, start first with the lower layers such as the infrastructure.

Published by

Jean-François Pironneau

Travaillant depuis 2003 sur les versions successives de SharePoint, je me suis spécialisé au fur et à mesure des années dans la partie infrastructure/technique, puis récemment dans la gouvernance de Microsoft 365.

Leave a Reply

Your email address will not be published. Required fields are marked *