Archive for January, 2011

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

SharePoint 2010 developing for performance article series:
In this series of articles I will briefly introduce you to some key concepts when it comes to developing for performance in our SharePoint 2010 applications.

Related articles in this article series

Part 1 – SP 2010: Developing for performance Part 1 – Developer Dashboard
Part 2 – SP 2010: Developing for performance Part 2 – SPMonitoredScope
Part 3 – SP 2010: Developing for performance Part 3 – Caching in SharePoint 2010
Part 4 – SP 2010: Developing for performance Part 4 – Logging
Part 5 – SP 2010: Developing for performance Part 5 – Disposal patterns and tools
Part 6 – SP 2010: Developing for performance Part 6 – CSS Sprites
Part 7 – SP 2010: Developing for performance Part 7 – Crunching those scripts
Part 8 – SP 2010: Developing for performance Part 8 – Control that ViewState

Part 5 (this article):
In SharePoint 2010 (and 2007 for that matter) there’s a few objects in the API’s that requires your special attention in order to behave properly. If you do not consider the disposal patterns and rules set forth, your application may very well suffer performance issues. In this article I will briefly touch upon the subject of disposing your SharePoint objects and foremost enlighten how important it is to dispose the objects!

What does Disposing mean and why is it important?

When I deliver training, there’s always the question about why disposing is important. In SharePoint there’s valid grounds for saying it’s important to dispose, more than just saying "It’s best practice". If you don’t properly dispose some of your objects in SharePoint you’ll quickly face performance issues since those objects don’t get caught and disposed by the Garbage Collector in a timely fashion as most other objects do in .NET.

What is a "dispose pattern"?

http://en.wikipedia.org/wiki/Dispose

The Dispose Pattern is the approach used to properly dispose and clean up the resources you’re using in your projects when programming in .NET (or other runtimes). Normally there’s an automatic garbage collector doing the cleanup for you – but in certain scenarios (like the ones described later in this article), you’ll need to manually dispose your objects.

IDisposable

In Microsoft .NET when an object inherits from the IDisposable interface it means that the Garbage Collector will call the .Dispose() method of that object when it’s no longer used. The Dispose() method in turn calls the Close() method which generally means you should call the .Dispose() method instead of the .Close() method to make sure the objects are properly disposed. Keep reading to see why this is so important!

Why is manual disposal really, really important in SharePoint?

Some of the objects you’re working with heavily in the SharePoint object model (for example the SPWeb and SPSite) are mostly using unmanaged code – and since the managed part of the code is quite small it doesn’t leave a large memory footprint and hence the Garbage Collector don’t necessarily dispose of that object – which means that it’ll be occupying server resources for a longer time if you don’t manually dispose of those objects.

What happens if I forget to dispose?

There’s several things that you may notice in your applications if you’ve implemented a solution that are not properly disposing their objects.

  • Memory consumption.
    • The consumption of your server memory may peak and the worker process (w3wp.exe) may consume a lot more memory than it would normally have to consume.
  • Application Pool recycling.
    • If the worker process consumes too much memory, it’ll recycle the application pool.
    • If you’ve got an underperforming application causing overwhelming  memory consumption the Application Pool will recycle more often.
  • Performance issues!
    • Slow response times
    • Timeouts
    • Unexpected errors
  • Headache
    • User headache
    • Support headache
    • Admin headache
    • Developer headache (ultimately)

In other words: Make sure you’re properly disposing your objects at all times!

Sandboxed Solutions and Resource Usage – Think about dispose patterns!

If you’re developing applications for the Sandbox in SharePoint 2010 (User Code Solutions / Sandboxed Solutions) you may be aware of the resource point system that will limit your application’s usage of resources on the server. This is a great way to keep the admins calm and developers keen on producing quality code.

A thing to note is that if you don’t correctly dispose your objects they will consume more server resources which in turn would lead to the resource points increasing. If the resource usage reaches the limits set forth by SharePoint for a sandboxed solution – it’ll deactivate it.

In other words: Make sure you’re properly disposing your objects at all times!

Let’s visualize the performance problem!

Okay, so now that I’ve got your attention – let’s do a quick performance test to see how the process handles the memory if we create the same application with and without disposal patterns in SharePoint.

I created a simple application that will work heavily with the SPSite and SPWeb objects on one of my servers. After hooking up a performance counter and monitoring the memory consumption repeatedly during a few hours of repeated execution it was easy to line down a conclusion which you can see in the chart below.

Performance summary

The following chart displays the same application with and without implementing the dispose patterns in a SharePoint 2010 execution environment.

Zimmergren Sample Memory Consumption Chart

You can see by the results of the two applications above that when we’re properly disposing our objects there’s a notable difference in the performance in our application – and hence the overall server resource usage.

In other words: Make sure you’re properly disposing your objects at all times!

How to: Implement dispose patterns in your SharePoint code

At this point we know it’s very important to dispose our objects in SharePoint – let’s take a look at how we can do that properly and what tooling and guidelines we can use to help us in this important quest!

Approach 1 – Manually calling Dispose()

The absolutely most general and simple approach to dispose your objects is to simply call the .Dispose() method of your objects:

 SPSite  site = new  SPSite ("http://zimmergren/");
 // Do stuff 
 site.Dispose();

Approach 2 – Encapsulating the statement in a using() block

A more common approach is to encapsulate the code in a using-block where the object will be automatically disposed when we’re reaching the end of our block.

     using (SPSite  site = new  SPSite ("http://zimmergren"));
     {
         // Do stuff 
     } 

Approach 3 – Utilize a try/finally block

Whenever you’re expecting to catch an exception or somehow might stumble onto exceptions and need to handle them – a better approach for disposing is to create a try-finally block and dispose the object in the finally-block.

Sample 1: Without exception handling

     SPSite  site = null ;
     try 
     {
         site = new  SPSite ("http://zimmergren");
         // do stuff 
     }
     finally 
     {
         if (site!=null ) site.Dispose(); 
     }

Sample 2: With exception handling

     SPSite  site = null ;
     try 
     {
         site = new  SPSite ("http://zimmergren");
         // do stuff 
     }
     catch (Exception  ex)
     {
         // Handle the exception 
         // Possibly send it to the logs 
     }
     finally 
     {
         if (site!=null ) site.Dispose();
     }

SharePoint 2010 Logging information: http://zimmergren.net/archive/2011/01/17/sp-2010-developing-for-performance-part-4-logging.aspx

Approach 4 – A mix of the aforementioned approaches

In some scenarios it might be a necessity to mix the aforementioned methods for disposing.

     using (SPSite  site = new  SPSite ("http://zimmergren"))
     {
         foreach (SPSite  oSite in  site.WebApplication.Sites)
         {
             try 
             {
                 // Do stuff 
             }
             catch (Exception  ex)
             {
                 // Log and handle exceptions 
             }
             finally 
             {
                 if (oSite!=null ) oSite.Dispose();
             }
         }
     }

Using SPDisposeCheck.exe to help us check for issues

It’s one thing to be pro-active and think about the dispose patterns when you’re developing your applications – but sometimes you can’t cope for every scenario in your complex code. Don’t worry though – you’ve got one of my best friends to help you out with that – the SPDisposeCheck.exe tool that Microsoft released to check for disposal problems.

Download and install it

There’s a new version of the popular dispose-check tool for SharePoint called SPDisposeCheck. You can find it here: http://code.msdn.microsoft.com/SPDisposeCheck

Grab your copy of the tool and hang on tight for the ride!

Configure it

When you’ve installed the tool, you can see a new menu option in the "Tools" menu:

image

Clicking the "SharePoint Dispose Check" menu item will bring up the SPDisposeCheck configuration menu like this:

image

In this dialog you can configure how the tool should behave, and if it should execute after each build. What’s even cooler is you can choose how to treat the problems.

When you’re building your Visual Studio project, the SPDisposeCheck will perform a post-build command (if you’ve ticked the Execute After Build checkbox) – and you’ll see the output directly in your Error-window:

image

Tip!
Always have this tool installed, and every now and then run the SPDisposeCheck to make sure your code is properly disposing your objects. Otherwise it’ll warn you like in the picture above :-)

False positives

When it comes to checking for dispose problems or leaks with this tool, it can sometimes give you something you’d refer to as "a false positive". What that generally means is that although the tool might report a problem, it really isn’t.

Ignoring reports

Sometimes with the SPDisposeCheck tool you’ll get quite a bunch of "false positives" reported, or for whatever other reason you’d like to ignore certain error messages from the SPDisposeCheck tool – you can do that by implementing the SPDisposeCheckIgnore attribute (available as source code in the SPDisposeCheck installation folder).

The following code snippet is taken from the "SPDisposeCheckIgnoreAttribute.cs" file in the SPDisposeCheck installation folder. Add this code to your project (you can change the namespace..):

 using  System;
 namespace  Zimmergren.SP2010.DisposePatterns
 {
     public  enum  SPDisposeCheckID 
     {
         // SPDisposeCheckIDs. 
         SPDisposeCheckID_000 = 0,  
         SPDisposeCheckID_100 = 100,
         SPDisposeCheckID_110 = 110,
         SPDisposeCheckID_120 = 120,
         SPDisposeCheckID_130 = 130,
         SPDisposeCheckID_140 = 140,
         SPDisposeCheckID_150 = 150,
         SPDisposeCheckID_160 = 160,
         SPDisposeCheckID_170 = 170,
         SPDisposeCheckID_180 = 180,
         SPDisposeCheckID_190 = 190,
         SPDisposeCheckID_200 = 200,
         SPDisposeCheckID_210 = 210,
         SPDisposeCheckID_220 = 220,
         SPDisposeCheckID_230 = 230,
         SPDisposeCheckID_240 = 240,
         SPDisposeCheckID_300 = 300,
         SPDisposeCheckID_310 = 310,
         SPDisposeCheckID_320 = 320,
         SPDisposeCheckID_400 = 400,
         SPDisposeCheckID_500 = 500,
         SPDisposeCheckID_999 = 999 
     }
 
     [AttributeUsage (AttributeTargets .Method | AttributeTargets .Assembly, 
         Inherited = false , AllowMultiple = true )]
     public  class  SPDisposeCheckIgnore  : Attribute 
     {
         public  SPDisposeCheckIgnore(SPDisposeCheckID  Id, string  Reason)
         {
             _id = Id;
             _reason = Reason;
         }
 
         protected  SPDisposeCheckID  _id;
         protected  string  _reason;
 
         public  SPDisposeCheckID  Id
         {
             get  { return  _id; }
             set  { _id = Id; }
         }
 
         public  string  Reason
         {
             get  { return  _reason; }
             set  { _reason = Reason; }
         }
     }
 }
 

Once you’ve done that, you can use the attribute on your methods and assemblies to tell them to ignore that specific item.

Example usage of the SPDisposeCheckIgnore attribute:

         [SPDisposeCheckIgnore (SPDisposeCheckID .SPDisposeCheckID_110, 
             "False Positive, nothing to see here, move along!" )]
         private  static  void  MyAwesomeMethod()
         {
             // Your method code with false positives 
         }
 

What if I’m an awesome coder already?

Too many times have I encountered problems in projects due to not properly checking for memory leaks.

Better safe than sorry. That’s all I’m going to say about that :-)

Summary & Links

What we’ve learned from this article is that you should always keep in mind how you handle your objects in your code – and especially when it comes to the SharePoint objects that are invoking unmanaged code like the SPWeb and SPSite objects (to name two common ones).

Make sure you’ve downloaded the latest version of the SPDisposeCheck tool to get the aforementioned fancy integration into Visual Studio 2010. It’s pretty awesome indeed!

Links / Resources

Enjoy!

SP 2010: Developing for performance Part 4 – Logging

January 17th, 2011 by Tobias Zimmergren

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

SharePoint 2010 developing for performance article series:
In this series of articles I will briefly introduce you to some key concepts when it comes to developing for performance in our SharePoint 2010 applications.

Related articles in this article series

Part 1 – SP 2010: Developing for performance Part 1 – Developer Dashboard
Part 2 – SP 2010: Developing for performance Part 2 – SPMonitoredScope
Part 3 – SP 2010: Developing for performance Part 3 – Caching in SharePoint 2010
Part 4 – SP 2010: Developing for performance Part 4 – Logging
Part 5 – SP 2010: Developing for performance Part 5 – Disposal patterns and tools
Part 6 – SP 2010: Developing for performance Part 6 – CSS Sprites
Part 7 – SP 2010: Developing for performance Part 7 – Crunching those scripts
Part 8 – SP 2010: Developing for performance Part 8 – Control that ViewState

Part 4 (this article):
In SharePoint 2010 (well, 2007 too for that matter) you need to think about proper logging in your applications to ensure that any problems, issues or other events are lifted to the ULS Logs (Unified Logging System) – that way the administrators can easily view the logs and track down problems with your applications. In this article I will talk a bit about how you can utilize the logging capabilities in SharePoint 2010.

ULS Logs

The ULS Logs are the main place for SharePoint to output it’s diagnostics information. We will take a quick look at how we can read the logs and obviously how we can write custom logging messages to the logs.

Reading the ULS Logs in SharePoint 2010

In order to read the ULS Logs you’ll need access to the SharePointRoot (14LOGS) folder. But to make the life even easier for us Microsoft released a tool called the ULS Viewer which you can download here: http://code.msdn.microsoft.com/ULSViewer

With this tool you can quite easily read through the logs in SharePoint 2010 without any issues.

There’s plenty of resources on the web about how to use the ULS Viewer, so go take a look at any one of them for some usage-instructions.

Download (docx): ULS Viewer documentation

Writing to the ULS Logs from you SharePoint 2010 application

The other side of the logs are of course writing to the logs. This is not a very hard task to do in SharePoint 2010, and I’ll outline the basic steps to do so here.

Normally I create a new class or at least a method to take care of the logging, and it can look like this:

public static void WriteTrace(Exception ex)
{
    SPDiagnosticsService diagSvc = SPDiagnosticsService.Local;
    diagSvc.WriteTrace(0,
        new SPDiagnosticsCategory("TOZIT Exception",
            TraceSeverity.Monitorable,
            EventSeverity.Error),
        TraceSeverity.Monitorable,
        "An exception occurred: {0}",
        new object[] {ex});
}

You can use the aforementioned code by calling the method like so:

try
{
    throw new Exception("Oh no, application malfunctioned! UnAwesomeness!!!");
}
catch(Exception ex)
{
    WriteEvent(ex);
}

It’s not very hard at all – once you’ve done that, you’re all set to kick off your custom applications and just call your custom logging method. Obviously you should create a proper logging class to take care of all your logging in your applications.

Results

Using the ULS Viewer you can easily track down the error messages by filtering on your category (in my case it’s TOZIT Exception)

image

image

Event Logs

Even though the ULS Logs takes care of most of the diagnostics logging today, it might be reasonable to output information into the Event Logs sometime.

Writing to the Event Logs from you SharePoint 2010 application

Just as when you’re doing ULS Logging, you can do logging to the Event Logs. It’s just as simple, but you replace the method "WriteTrace" with "WriteEvent" like this:

public static void WriteEvent(Exception ex)
{
    SPDiagnosticsService diagSvc = SPDiagnosticsService.Local;
    diagSvc.WriteEvent(0,
        new SPDiagnosticsCategory("TOZIT Exception",
            TraceSeverity.Monitorable,
            EventSeverity.Warning),
        EventSeverity.Error,
        "Exception occured {0}", new object[] {ex});
}

Results

You can view the logs in the Event Logs on your SharePoint server as you would read any other logs.

image

Can I do more?

There’s plenty of cool things to do with the logging mechanism in SharePoint 2010, so you should definitively get your hands dirty playing around with it.

If you for example want to tag the log entries with your company name, clients name or project name – you can easily change that behavior as well. Take a look at my friend Waldek’s post about it here: http://blog.mastykarz.nl/logging-uls-sharepoint-2010/

Related resources

Summary

As a part of the article series focusing on some general guidelines for performance in your applications, logging is a major player. If you master your logs in terms of monitoring and custom application logging you will quickly come to realize how valuable it is.

This is intended as a starting point for you to get familiar with the logging-capabilities in SharePoint 2010.

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

SharePoint 2010 developing for performance article series:
In this series of articles I will briefly introduce you to some key concepts when it comes to developing for performance in our SharePoint 2010 applications.

Related articles in this article series

Part 1 – SP 2010: Developing for performance Part 1 – Developer Dashboard
Part 2 – SP 2010: Developing for performance Part 2 – SPMonitoredScope
Part 3 – SP 2010: Developing for performance Part 3 – Caching in SharePoint 2010
Part 4 – SP 2010: Developing for performance Part 4 – Logging
Part 5 – SP 2010: Developing for performance Part 5 – Disposal patterns and tools
Part 6 – SP 2010: Developing for performance Part 6 – CSS Sprites
Part 7 – SP 2010: Developing for performance Part 7 – Crunching those scripts
Part 8 – SP 2010: Developing for performance Part 8 – Control that ViewState

Part 3 (this article):
In this article I will talk about some different techniques for managing caching in your applications. One of the most important thing for most projects today is to keep the performance to a maximum under heavy load times. Caching helps out in achieving parts of that goal.

Some caching techniques in SharePoint 2010

In SharePoint 2010, there’s a few different ways to cache data. In this section you can read about a few of those approaches. Most of the caching techniques I use regularly as a developer derives from or is a direct usage of the capabilities of the .NET framework.

Output Caching (Configurable)

The concept of Output Caching is something that natively comes with SharePoint 2010, as it builds on and relies on ASP.NET caching techniques. This means that you can configure your SharePoint 2010 site to cache the Pages it outputs. The reasoning behind caching a page is obviously that it takes time to generate the content on any page, and on a heavily accessed site it would be a performance impact to generate a new page on every request – that’s where Output Caching comes in handy.

There’s a few goodies about Output Caching, as well as a few gotchas that you should be aware of before taking the journey of configuring your sites for Output Caching;

  • Positive: Quicker response time for your cached pages, faster to render to the client.
  • Positive: Saves on CPU, since it doesn’t have to re-do all the calculations every time.
  • Positive: You can customize Output Caching by using Cache Profiles.
  • Positive: The caching mechanism can store different versions of the resources cached depending on the permissions for the requesting user.
  • Negative: Caching obviously eats more memory as it needs to cache the pages.
  • Negative: Possibility for inconsistencies between WFE’s in a multi-server farm.
  • Negative: Output Caching is a SharePoint Server 2010 capability.

You can create custom caching profiles for your SharePoint 2010 site which allows you to modify and configure the way things are cached – and what should be cached.

Read more: How to configure Output Caching
Read more: Create a custom cache profile using VaryByCustom event handler

Object Caching (Configurable)

In SharePoint Server 2010 you’ve got the option to use Object Caching as well, which is a mechanism to cache specific page items. This is especially likable if you’re playing around with Cross-List data queries and need to cache the results of such a query.

Read more: Object Caching

BLOB Cache (Configurable)

In SharePoint 2010 you also have something called the BLOB Cache, which is a disk-based caching mechanism that caches resources on the disk. Normally these resources are files served by a web page and are named Binary Large OBjects (BLOB).

Normally the BLOB cache will cache files served by the web request like images and video clips.

In web.config you’ve got something similar to the following line which lets you know what file types are cached. You can of course add or remove file types here:

<BlobCache 
    location="D:BLOB"
path=".(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$"
    maxSize="10"
    enabled="false" />

Read more: Configure cache settings for a Web Application (SharePoint Server 2010)
Read more: Configure the BLOB Cache

Caching in code (Programmable)

While we know that there’s pre-configurable caching available in SharePoint 2010 (like the Output Cache and BLOB Cache), there’s obviously still a need to create custom caching routines in your applications.

In order for your custom applications to run efficiently and save on server load, you need to consider the importance of using proper caching in your applications.

For instance, if you’ve created an application that is (on every request) fetching information from a database or a SharePoint list (SPList), do you really need that data to be fetched directly from the source – or could you live with having it cached for a few minutes? If it’s not super-important data we’re dealing with that doesn’t need to be up to date every second and every request – please consider building some caching mechanisms in your applications.

There’s a few different approaches to caching in your custom applications, the most common being the ASP.NET Caching (Read about how you can cache a Web Part).

To be honest, there’s no need to write about all the different code-samples you could use for caching right here, as the guys at Microsoft did an excellent job talking about it in this Best Practice article:

Read more: Common coding issues when working with the SharePoint Object Model

Note that the aforementioned article is for SharePoint 2007 (WSS 3.0) originally, but these techniques still apply.

Summary

In this article you’ve read about a few approaches to make your applications perform better in SharePoint 2010. These techniques are a fundamental part of development and configuration when it comes to playing around with SharePoint and making it behave properly in terms of responsiveness and performance.

I’ve been getting a few requests for talking about some various caching techniques in SharePoint, so there you have it. Go have a read at those links and you should be all set to start the adventure that is caching!

Read more: Planning for caching and performance

Enjoy!

A look back at 2010

January 6th, 2011 by Tobias Zimmergren

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

A new year dawns, as we move into 2011. There’s plenty of awesome things going on that will shortly be announced for 2011.

Right now, though, let’s focus on what 2010 looked like. Here’s a short summary of some of the highlights.

Popular articles from 2010

The main focus of my blog the last few years have been to produce quality articles to help people (myself included) to better understand certain development tasks in SharePoint.

Here’s a list of some of the most popular articles I’ve written in 2010, in no particular order:

Events in 2010

What makes for a great year if not a great conference? Better yet, what makes for a great year if not for several great conferences?

During 2010 I was attending and speaking at various conferences, user groups and events around the globe. I’ve got to say that it’s quite awesome to be part of the SharePoint community.

Some of my favorite events of 2010 includes these;

There was a few more conferences I was attending, but the aforementioned are the ones I thought brought significant value for the attendees (myself included) in terms of technical content, market understanding and building your social and professional network!

SSUG – Sweden SharePoint User Group

It’s with great pleasure that I can announce that the SSUG group is expanding and we’ve got a huge member base – we’re growing each day. What’s even more impressing is the quality and quantity of the people attending our meetings.

Without our members showing up on our meetings, we wouldn’t be able to sustain such a great group – a thank you goes to our members, as always!

MVP x3

For the third time in a row I was awarded the MVP award from Microsoft for my community engagement. Let’s hope that 2011 will be just as awesome and that we will spend many joyful hours together online and offline.

Summary

2011 is here, let’s embrace it like we always do with a new year and rock the socks off! There’s plenty of cool things going on in 2011 that you will not want to miss out – more on that later.

Follow me on Twitter: http://www.twitter.com/zimmergren