Chris’s SharePoint Reflections

Just another weblog

  • Chris Zhong

    IT consultant Australia

Archive for the ‘Performance’ Category

Dispose SPWeb/SPSite in MOSS/WSS

Posted by chrissyz on January 16, 2010

Why we need to dispose them?
In SharePoint, each SPWeb and SPSite object holds a reference to an SPRequest object which holds reference to a SharePoint COM object. In order to ensure that the SPRequest object will release the COM object as well as all the memory allocated by this COM object, it is necessary to dispose the unmanaged resources in a timely fashion. Though internally, .NET framework has a finalizer to release the native memory, however, as it runs on a single thread, it generally cannot keep up with cleaning these objects if they are being leaked many times in a second.
The consequence of not explicitly disposing unmanaged resources in a timely fashion can lead to not having enough memory and quickly consume memory. Furthermore, as each COM object is responsible to communicate with the backend SQL Server, in case the SPWeb object is not disposed when it is no longer used, then the connection to the SQL Server will stay open. Each connection to the database requires a TCP port for the communication. By default, only 5000-1023=3977 ports are available ( MaxUserPort Registry), which means on a single machine per default you cannot have more than 3977 open connections to other applications. So, besides the fact that not disposing SPWeb and SPSite will lead to higher memory consumption which finally can lead to out of the memory exceptions, the machine might also run out of TCP ports.

Symptoms/Issues which users can experience when the unmanaged objects are not disposed correctly
1. Database Connectivity
When object are not disposed correctly, you can find a lot of the following database related error messages in your SharePoint WFE event log and ULS log.
When all the TCP ports are in use, this will result in the following error message/event logs
• Event ID 3355 errors: Cannot connect to SQL Server. XXX not found. Additional error information from SQL Server is included below. [DBNETLIB][ConnectionOpen(Connection())]SQL Server does not exist or access denied.
• Event ID 27745 errors: Unable to connect to the database XXX. Check the database connection and make sure that the database server is running
• The ULS log shows the same database related error as above

2. ULS Logs errors
The ULS log will show errors when objects are not disposed correctly. The database related ULS log errors are already written down in the previous section. This section will focus on the SPDispose related error message in the ULS logs (by default located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS). The error message will be like this

1/14/2010 14:15:48.91 w3wp.exe (0x145C) 0x04AC Windows SharePoint Services General 8l1n High An SPRequest object was not disposed before the end of this thread. To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it. This object will now be disposed. Allocation Id: {951F9932-6C3F-4FC9-AFA8-824892FA8142} To determine where this object was allocated, create a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings. Then create a new DWORD named SPRequestStackTrace with the value 1 under this key

Best Practices:
1. Practice the best coding practice regarding dispose the SPWeb/SPSite. Some good resources can be found on the internet.

2. SPDispose Checker Tool
On MSDN a tool is available which can check your developed assemblies. This tool will check most of the common dispose issues, but will not check all issues that can occur related to disposal of SharePoint objects. So you should fix at least all issues which are found after running the SPDispose Checker and then continue applying the best coding practices

3. Be aware of the out-of –the-box memory hungry component
Be aware of some of the OOTB components can require huge amount of memory when incorrectly configured. Navigation control is a good example. For each item in a navigation control that has to be retrieved through the sharepoint site map provider SPWeb and SPSite will have to be created. Though the control itself ensure that those objects are disposed correctly before the request ends there are often several of these objects in parallel in memory while the control is being rendered.
4. Switching to 64-bit architecture
In 64-bit architecture, the virtual address space is no longer limited to 2GB. This also means that memory fragmentation will not have the negative effects as in 32-bit architecture. However, even in 64-bit architecture, you still have the same limitation regarding TCP ports.

Posted in development, Performance | 1 Comment »

SharePoint Performance Guide

Posted by chrissyz on January 19, 2009

Performance always attracts people’s attention (End user especially). Here are some recommendations/trouble shootings for SharePoint sites performance issues.

Firstly, let me explain two fundamental concepts in any website’s performance.

Throughput: In Wikipedia, the throughput is the average rate of successful message delivery over a communication channel. Get it? J My “customer-understandable” interpretation of that is how many pages can a system serves over standard unit of time. Be aware the difference of typical and peak user load. Typical user load means average requests over standard unit of time. As for peak, you need to take concurrency into consideration. The rule of thumb for planning will be: plan for peak, assuming 10% concurrency.

Latency: a time delay between the moment something is initiated and the moment its first effect begins. My interpretation is how fast the page loaded. There are three factors that have impact on latency:

·         Server processing: SQL processing, number of SQL round trip, AJAX processing, security trimming etc.

·         Client processing: JavaScript, CSS, AJAX request, HTML load, Client machine specifications etc.

·         Wire transfer : bandwidth, size of download, etc

Suggestions for poor throughput:

·         Check your SQL performance, like CPU utilization, how heavy is the load etc. Always use SQL best practice for performance. Microsoft has a white paper provides key recommendations and best practice to help you to plan and monitor your SQL Server Storage requirements to support optimal performance

·         Make sure there are no conflicts in asynchronous operations and timer jobs. For example, you are not going to run 50 custom jobs all at 2am in the morning. 🙂

·         Carefully plan for your site hierarchy, site content and deployment. Every time you create a web application, you will lose 56M memory before you start loading anything. Therefore, you want to try to minimize the number of web applications and application pools and also limit the number of Shared Service provider.

·         Check custom code. The downside for writing custom web parts and event handlers in SharePoint is the sacrifice of performance if handled without caution. Developers need to write efficient code like creating and destroying SharePoint objects, monitoring SOAP and database connections and round trips, optimizing how much XML you use etc.

·         Looks for hardware/network components configuration error.


Suggestions for poor latency:

·         The number one killer for latency is custom web part. Watch for SQL round trips, unnecessary data, excessive client side scripting.

·         Check for page payload. OOTB, the main page download size should be around 200kb and shouldn’t be significant higher. We will try to use page compression where possible. For example, you have the option to make CORE.JS available on Edit mode for performance improvement.

·         Using Caching strategy. You can turn on BLOB and Output catching. There is an article on Technet listing all SharePoint caching options:   However, be careful that catching could actually make performance worse if handled improperly as it can take up memory and processor time.


Besides the above ones, there are some other general suggestions towards improving SharePoint site performance.

·         Recommend 64 bit for back end services which can leverage additional addressable memory, like database server, Index server.

·         Using server farm and have dedicate roles for each single server

·         Reduce the number of unghosted pages. Unghosting reduces the system efficiency and performance as the request will have to go to the database to fetch data instead of just hitting the cache. Example of this is creating site definitions are much more efficient than using site templates created through the UI.

Finally, there are a couple of testing tools which can help you trouble shooting:

·         Visual Studio Team System 2008 Test Edition

·         SharePoint Test data load (WSSDW.exe) is a native Microsoft tool that can be used to perform SharePoint load testing. The tool populates data for testing deployments of MOSS 2007 and is a command-line executable program that accepts an XML configuration file that specifies the objects to be populated.

·         Microsoft Operation Manager


Posted in Performance | Tagged: | 1 Comment »