Overroot Blog

SharePoint quite often performs slow because of the fact that every bit of information served by SharePoint is saved in a database including images, documents, list data, dynamic pages, e.t.c.

There are different ways of improving performance some of which are mentioned on Chris O’Brien’s blog. We know that SharePoint is a ASP.NET application and there are many established techniques for improving performance of a ASP.NET website or any website in general, that can be applied to SharePoint as well.

The ones I’m going to talk about are those which do not require any programming.

• Minify and combine Javascript and CSS
  This reduces the no. of request a browser makes for retrieving and rendering a page. When we combine multiple javascript files and minify the final file, we’re effectively reducing ‘N’ no. of requests to one and the downloaded payload is also smaller in size. Add client side  caching to this and same client won’t even request the same set of javascript files on any subsequent pages.

  NCachePoint and Aptimize provide this in their SharePoint performance accelerator products.
  

• CSS Sprites (Combine Images)
  Combine images into a single image and use CSS sprite technique to render different portions of that image on the page. This also helps in reducing the no. of trips a browser makes to the server. This technique can also take advantage of client side caching.

  NCachePoint and Aptimize provide this in their SharePoint performance accelerator products.
  

• Session Caching
  Saving sessions in database allows you to share the session among multiple servers in your farm but the database becomes the bottle neck for the SharePoint farm. To get around this you can save your sessions in a distributed cache which can allow you to get rid of sticky routing and still not be dependent on a single machine to serve the sessions.

  NCachePoint allows you to cache your sessions in a distributed cache that comes free with it.
  

• List Caching
  SharePoint makes heavy use of list data which is stored in database. Database is optimized to store relational data then why is the performance of lists not optimal?
  In SharePoint all  list data is stored in a single table called AllUserData. This table has a long list of columns  that can save every perceivable type of data in each column of a list entry.

  Since a user can  define any type of list with any no. of columns of any type, querying this table becomes difficult and hence quite inefficient.

  One way to get around this is to cache the output of lists and serve the cached output each time list is retrieved.

  NCachePoint provides the list caching feature.
  

• ViewState Caching
  With so many web parts loaded on a single SharePoint page, we get many ASP.NET controls loaded at the same time all of which have to save some state that needs to be preserved across postbacks. Typically viewstate is saved in the page that is rendered to the browser and it goes back and forth between post backs (User clicks and interaction with the controls).

  You can use a 3rd party solution to cache view state in a distributed cache and
  prevent this payload from traveling between the server and client for effectively reducing the request size and quicker response time.

  NCachePoint provides viewstate caching for SharePoint
  

• Externalize the BLOBs to RBS or EBS
  All documents that are uploaded in SharePoint, are saved in database as BLOBs. This makes your SharePoint database grow abnormally large and bloated. Sql Server is optimized for relational data not BLOB data and hence saving blobs in database has a severe performance hit. If you externalize the blobs to EBS (External BLOB storage) or RBS (Remote Blob
  Storage), you’ll not only see performance gain but also you can use a cheaper storage
  to save the BLOBs and hence save yourself from storage cost.

  EBS was an interface provided with WSS/MOSS 2007 where as RBS is an interface provided by Sql Server 2008. EBS is supported both in SharePoint 2007 and SharePoint 2010 where as RBS can only be used with SharePoint 2010 and Sql Server 2008.

  NCachePoint, AvePoint, StoragePoint all provide EBS and RBS for SharePoint for BLOB externalization.

If you buy an off the shelf solution for increasing SharePoint performance you can
save yourself from the cost of development and maintenance of any custom solution
which could potentially be error prone if not done right.

Alachisoft has recently released NCachePoint 2.0 (BETA) which has all the above mentioned features and is available at http://www.alachisoft.com/ncachepoint/index.html

Their product sits in front of a distributed cache which saves all your content so the lookup of any resource is amazingly fast and helps a lot in improving performance of SharePoint farm. The good news is that they have a free edition called NCachePoint Express which can be used on WSS 2007 and SharePoint Foundation 2010 (WSS 2010).

Event logging is a standard way for applications to record important events. Most of the windows applications log their messages, warnings and errors in event log.

Microsoft SharePoint Server, although, has it’s own centralized logging mechanism but it does not log it’s messages to event log. SharePoint LogViewer has a new feature in it’s most recent version (v2.5) to record all or few of the events in window’s event log. You can select the minimum SharePoint severity level from which the logs should be reported to event log.

In SPLV, we used System.Diagnostics.EventLog class to write messages to event log.
Following is the C# code to write log entries to event log.

string source = "Demo Application";
if (!EventLog.SourceExists(source))
EventLog.CreateEventSource(source, "Application");
EventLog.WriteEntry(source, "Message!", EventLogEntryType.Error);

Although, these lines of code work fine, it, however, requires the application to run under the administrator’s account otherwise it may throw a System.Security.SecurityException.

To have this feature working in SPLV, we recommend it’s users to run SPLV under the administrative privileges.

SPLV 2.5 has all the promised features and more.
A complete list of features currently available is as under:

• View multiple SharePoint log files at once
• Search by any field
• Filter the log by any field
• File drag & drop support
• Live monitoring for entire farm
• Export filtered log entries
• Bookmark log entries
• Get popup notification of SharePoint log events from system tray
• Receive email notifications on errors
• Redirect log entries to event log
• SharePoint 2010 Support
• Run at startup

Share Point Log Viewer 2.5 is the best log viewer available now at http://sharepointlogviewer.codeplex.com
We’ll be releasing its website soon. stay tuned.

The classic way for modifying page markup at runtime as we know it, is using ASP.NET Response Filter.
People have been using response filter for pulling off different tricks in SharePoint 2007 and it all worked fined until SharePoint 2010 arrived.

SharePoint 2010 uses ASP.NET substitution caching a.k.a Post Cache Substitution which allows it to cache the entire page except for certain portion of the page which continues to remain dynamic. More explanation can be found at http://blah.winsmarts.com/2006/05/26/aspnet-20–post-cache-substitution.aspx

Anyways so the thing is post cache substitution is not compatible with response filters. Here is the official Microsoft kb article http://support.microsoft.com/kb/2014472

The only solution they suggest is to either not use substitution caching or not use response filters. They are mutually exclusive. Well since we can’t change SharePoint the only option left is to not use response filter. So there isn’t really any solution right now. If you figure it out do leave out a comment on this post.

With SharePoint 2010 on the verge of it’s release, it is very important to make your existing SharePoint applications compatible with it. SharePoint LogViewer was initially built for viewing SharePoint 2007 logs but it still could be used to view SharePoint 2010 logs until one of the most powerful feature ‘Live Monitoring’ was introduced.

‘Live Monitoring’ requires you to run SPLV on machines where SharePoint is installed. Earlier it was only able to detect SharePoint 2007 while SharePoint 2010 logs could not be monitored. SPLV detects the SharePoint installation by reading registry keys. To find the SharePoint location on a machine, SPLV used to read a registry entry ‘Location’ under the path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0.
But this only worked for SharePoint 2007 as SharePoint 2010 has a different registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0.

Now SPLV tries to locate any of the above mentioned two registry keys to detect SharePoint installation which makes it possible to monitor Live logs for both SharePoint 2007 as well as SharePoint 2010.

For those of you who want to deploy their SharePoint 2007 solutions on SharePoint 2010, Andri Yadi’s article SharePoint 2010 Solution Installer may help.

Download the latest version of SPLV from here