Chris’s SharePoint Reflections

Just another weblog

  • Chris Zhong

    IT consultant Australia

  • Advertisements

Archive for January, 2009

The SharePoint tools we love…

Posted by chrissyz on January 30, 2009

In my previous post, I introduced a few development tools that essential for SharePoint development. This time, I will introduce a couple of add-ons. All developers, it is not necessary to have them, but for me, they are like these little cherries on the cake.:)

  • SPDisposeCheck  Get it while it is hot. 🙂 Microsoft’s latest release. It checks the assemblies that use SharePoint API and provide assistance in correctly disposing certain SharePoint Objects like SPSite and SPWeb. It will help us to follow the memory management best practice when coding against SharePoint API with IDisposable Objects and avoid unnecessary memory leak in the code.
  • SharePoint Manager 2007 An excellent SharePoint object model explorer and management utility. It enables you to browser every site in your local farm and view and change every property. You can also enable/disable features through it.
  • SPTraceView Nice tool for trouble shooting SharePoint. It processes all sharepoint diagnostic tracing in real time (ULS tracing) and notify you using a balloon-style mesages in the tray. Especially when it comes to solution deployment time
  • Application Pool Recycle Utility A small tool providing quick access to common IIS tasks which are useful on SharePoint development box.
  • SharePoint Search Service Tool It is bascially a rich client for the Sharepoint Search.asmx. Very useful to help you build complex search queries. It is actually a You can manipulate the scope and managed properties through the UI instead of going into SSP. This tool can also be used for troubleshooting
  • U2U CAML Builder No need to say how important this tool in our daily work. It also reminds me my very good friend Patrick Tisseghem as well. Patrick, we miss you!
  • WssAnalyzeFeatures Small tool allows to verify if the feature definition files for all installed features are present on the file system. It also help you to verify the features used in the site collections and sites are installed on the server.
  • The last but not the least Microsoft Best practices Analyzer for WSS and MOSS  Do a health check for your SharePoint farm, is that your new year resolution?:)

Posted in Uncategorized | Leave a 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 »