How to troubleshoot performance issues in SharePoint custom code on your own? Part 3- Slow
This post is a contribution from Paul Chan, an engineer with the SharePoint Developer Support team
Another popular performance issues I have seen when working on customer’s issues is slow response. Obviously, this blog article addresses a slow scenario.
NOTE: If you feel needed or press on time, feel free to contact Microsoft and create a support case to work with us, instead of dragging the resolution of the issue for too long until the last minute.
The symptom of a slow issue could be confused by high CPU usage. When a process is using high CPU utilization, its response is obvious slow. This condition is not considered a slow issue but high CPU instead. Similarly, a slow response could also being caused by high memory (or I should say high resource) usage. Failing to release resource from the class objects being instantiated in the code could lead to a slow response; especially if the resource related to network connections. In theory, it is not high memory usage will cause a slow response directly, but indirectly. For a “real” slow issue, it means the CPU and memory usage are usually low, which technically means that the w3wp.exe process is waiting on something; more likely some requests to a remote process, web service, SQL, etc.
If you do have access to the custom code and afford to change and redeploy it, then the most simple way is to add time logging in the code; i.e. either log the time at selected location in the code and record the time (or the duration of a method or section of the code) into a text file or anything available. Then simply check the time and reference in the code will give you an idea where in the code execution is taking a long time. The DateTime.Now, the System.Diagnostics.Stopwatch, or the Microsoft.SharePoint.Utilities.SPMonitoredScope will be useful in this approach.
If you can’t change the code, try to see if the code will attempt to connect to any remote services, and then check the remote side of the request and see how long it takes. For example, if the code will try to access a web services hosting by a website on an IIS server, simply check the Time-Taken column value in the IIS log of the hosting website will give you an idea how long the request to the web method took.
For SharePoint specific issues, the access to lists with a lot of items (e.g. 2000+ items) could be a problem. Complicated CAML queries should be avoided, prevent expensive operations (e.g. break inheritance, create new site, etc.). In addition, the ULS log might give you some clue (e.g. a query duration time) to show where the slowness could come from.
For a tool that could help troubleshooting slow response, a code profiler will be nice, but not everyone has access to one. There is one I mentioned in “How to troubleshoot performance issues in SharePoint custom code on your own? Part 1 – High Memory Usage” that is not very friendly but could somewhat do the job (with certain limitations); i.e. NP .NET Profiler. You can read about it (contains some simple walkthroughs):
Can be downloaded from here:
https://www.microsoft.com/en-us/download/details.aspx?id=35370
NOTE: For any performance issues that you don’t feel comfortable to handle, please feel free to create a support case and work with Microsoft support.
Comments
- Anonymous
November 30, 2014
I like this blog series. Thank you. - Anonymous
December 28, 2014
This is a useful one again. Thanks for the links about the NP .NET Profiler. This has a huge potential.