Performance Issues on Customized SharePoint Applications

Written By: Abin Jaik Antony -- 8/10/2011 -- join -- contribute -- (19) comments -- printer friendly version

Rating: Rate --

Categories: Infrastructure, MOSS 2007, System Administration, WSS3

< Prev - 1 | 2 | 3 | - Next > | Become a paid author


The scope of this tip is to explain the ways to handle performance issues on a customized SharePoint application. Usually these kind of performance issues happen due to the way in which the SharePoint API has been used in the code or due to the application architecture design for accommodating various business needs.


The performance degradation occurs mainly due to following reasons.

  1. Memory leakage.
  2. User concurrency that causes several threads to execute the same SharePoint API functionalities and method calls.
  3. Abnormal size increase of the content database transaction log file.
  4. Accessing data from large SharePoint lists.

The above factors cause deadlocks and thread execution time outs which may end up with improper functionalities of the application.

Let's look into the several ways to handle these issues...

1.† Memory Leakage:

We have to use the SharePoint API very carefully, otherwise it will cause huge memory blot ups. The usage of SPWeb and SPSite objects will cause memory leakage issues if these objects are not handled or disposed of properly. The one way to analyze the code for non disposed SharePoint objects is to check an entire solution with a tool named SPDisposeCheck. This tool is a Visual Studio add-in and on the compilation of the SharePoint VS solution it will point out lines of code where there is a need to dispose of the objects after the execution point. The best way to use the SharePoint API objects is to maintain an object scope inside using {} blocks.

Correct Usage Sample :

    	using (SPSite site = new SPSite ("URL"))
		using (SPWeb web = site.OpenWeb())

Incorrect usuage :

    			SPSite site = new SPSite ("URL");
			SPWeb web = site.OpenWeb ();


There will be a curiosity on every developerís mind as to why the .NET garbage collector is not taking care of this kind of object disposal. The answer is quite simple; it is like every SPWeb/SPSite has an internal reference SPRequest class which uses unmanaged COM resources to connect to the backend SQL Server. Because of this we need to explicitly dispose of these objects.

There is a very nice MSDN blog by Roger Lamb regarding SharePoint Object disposal patterns.

< Prev - 1 | 2 | 3 | - Next >

Learn more about SharePoint

Sponsor Information

Copyright (c) 2010-2017 Edgewood Solutions, LLC All rights reserved
privacy | disclaimer | copyright | advertise | contribute | feedback | about
Some names and products listed are the registered trademarks of their respective owners. |