Web part devlopment best practices

In this blog I show you how to verify that your used Web Parts – custom built or from 3^rd party vendors such as AvePoint, K2, Nintex, Metalogix … – are not suffering from the top problems we see in the SharePoint world:

• Inefficient Database Access: Learn how to use the SharePoint Object Model to avoid unnecessary roundtrips to SQL Server and loading too much data!
• Memory Leaks: The SharePoint Object Model makes it easy to access data but it very often results in memory leaks as developers need to take care of releasing these resources manually!
• Deployment Mistakes: Web Parts are not just config files. Make sure you deploy all dependencies to avoid functional and performance problems!
• Bad Web Performance: Bloated SharePoint pages and problematic JavaScript are the top web performance issues in SharePoint. Follow the best practices!
• Web Part Usage Gone Wild! If you have too many SharePoint Users with Admin privileges its likely that too many Web Parts are installed for trial but are never uninstalled if not used anymore. This leads to overloaded SharePoint installations!

If you want to follow along you can easily do a check on your SharePoint Installation. Either use your existing diagnostics/monitoring tools or download our Dynatrace Free Trial with ourSharePoint FastPack. If you are a SharePoint Web Developer feel free to show off and share your best practices with me. More details on that at the end of my blog!

Now let’s dig deeper into these 4 problem pattern areas:

Inefficient Database Access

I raised the problem of inefficient or actually bad database access via the SharePoint API back in 2009/2010. I found that many Web Part developers were using the SharePoint Data Access API wrongly, to e.g: iterate through lists and views – leading to thousands of SQL roundtrips to query too much data for a simple list output. This resulted in high I/O on SQL Server and high Memory Usage in IIS.

Now in 2015 we still see these problems as shown in the following Transaction Flow for a SharePoint Blog. It visualizes the database roundtrips of a single request when accessing SharePoint Blog related Web Parts:

Identify problematic Web Parts by looking at the number of SQL Statements executed. Executing 211 SQL Statements is a good indicator of a data access problem

If you experience similar issues with your SharePoint blog check out the Slow SharePoint Blogdiscussion on stackexchange.com.

Dynatrace Database Dashlet shows all individual SQLs being executed by each Web Part. Makes it easy to spot which Web Parts are having bad database access patterns

Memory Leaks

Despite having a Garbage Collection (GC) mechanism on the .NET platform it doesn’t mean that applications don’t suffer from memory leaks anymore. Based on my experience, memory leaks happen very frequently as many developers are not familiar with basic concepts of proper memory management. Before leaks may cause the whole server to crash it is the Garbage Collection that tries to “clean up the mess.” Everyone running SharePoint should therefore always keep an eye on general memory usage patterns as well as Garbage Collection (GC) activity.

As a first step I always look at overall memory consumption and the impact of Garbage Collection on CPU but also response time of SharePoint page requests

In general I would say that we see two types of Memory Leak patterns in SharePoint: leaks introduced with custom objects that can’t be collected by the GC and leaks introduced through incorrect usage of the SharePoint Object Library. 

The following screenshot highlights the 3 steps to identify whether your SharePoint Web Parts are leaking SPSite and SPWeb objects which is very easy to achieve especially in SharePoint 2007 & 2010:

Watch out who allocates SPSite and SPWeb and which of these objects are not properly released as this leads to memory leaks and crashes

Deployment Mistakes

I already covered the most common deployment mistakes in my SharePoint Deployment Health Check blog. For Web Parts I want to highlight the two most common deployment mistakes I see:

1. Missing or incorrectly deployed binaries
2. Incorrectly configured Web Parts leading to bad behavior.

The following screenshot shows the error information you can capture showing that a Web Part was not correctly deployed, as SharePoint can’t load all of its dependencies. If you want to learn more about this read up on the details on my deployment check blog.

When a Web Part is not correctly deployed SharePoint will throw Exceptions like the one above. End Users will only see a blank area

Bad Web Performance

For the end user, SharePoint is a web application. That’s why all rules of Web Performance Optimization apply just as well to SharePoint and every single Web Part on your SharePoint pages. When analyzing Web Performance on SharePoint sites, I often see

1. images that are too large/ too many images
2. uncompressed JavaScript and CSS files
3. slow and faulty JavaScript code

The following screenshot shows a customized SharePoint page with a “Page Weight” of 2.6MB. That may not sound a lot to you – but if you have hundreds of employees accessing this page on a regular base from different locations around the world you will get a lot of complaints about poor end-user performance.

2.6MB for your SharePoint Site Home Page is simply too big. It requires lots of bandwidth and will result in bad user experience

In the screenshot above I simply used the Inspector – which is a built-in browser diagnostics tool for Firefox and Chrome. There are many other tools out there such as YSlow, PageSpeed, SpeedTracer or Dynatrace that do the same checks and give you recommendations on how to optimize across all major browsers.

I’ve blogged about many web sites that suffered from these same issues that I now also see in SharePoint implementations. If you want to learn more check out my Top 10 Client-Side Performance Problems.

Web Part Usage Gone Wild!

The more people you allow to install Web Parts the harder it is to keep track of it. Make sure you have a small group of SharePoint Admins that know which Web Parts are really necessary and which ones are no longer needed. Make sure you clean out “the garbage” once in a while to keep your SharePoint installation as clean as possible!