Background
Before I get into any detail about this particular problem and its eventual resolution, it might be helpful to provide a little background information about why we're doing this and how we got here.
Windows SharePoint Services 3.0 (WSS 3.0) provides a very extensible solution platform for the professional Microsoft .NET developer and is becoming increasingly more popular among companies looking to build collaboration and workflow into their environment.
I have been working on a project for the past couple of weeks that consists of a Windows SharePoint Services 3.0 small server infrastructure and several custom application pages written in ASP.NET C# via the SharePoint Object Model.
The focus of this post will be a small subset of what has been built to date. We'll call this piece the Master Data List. This Master Data List was created as a standard Custom List in SharePoint with several new columns created for the purposes of collecting data relevant to active projects for this department. It was decided early on that the standard newform.aspx, editform.aspx and dispform.aspx pages that come by default with the instantiation of a new list were not going to be sufficient for the purposes of this list. There were several reasons for this:
We wanted to dramatically change the layout of the page, including background colors on specific sections, fonts, hyperlinks etc.-
We wanted complete controls over the types of validation we were doing -
The page itself was to consist of some aggregated data, in the form of drop downs and data grids, that was being pulled from several different lists within the same site and presented on the editform.aspxand dispform.aspx pages
Problem
Because of the complexity of these pages and the amount of aggregation we were doing, the average loading time for the edit and display forms was about 30 seconds (give or take a few seconds). The objective of this performance evaluation was to bring down the total time for page load to less than 10 seconds which would be a more reasonable end user experience.
Solution
I did manage to eventually bring down the loading times to under 10 seconds, so a 70% increase in performance, with several different techniques which I will now discuss in some detail.
- The first thing I did for both the editform.aspx page and the dispform.aspx page was to remove all <asp:Label> objects and replace them with plain text. If I wasn't planning to manipulate the label object in any way in the code behind, there was no need to create a control of this type. Text was sufficient for these purposes.
- The second thing I did was to remove all Telerik textbox and combobox controls except where required and converted them to asp:dropdownlists and asp:textboxes.
- The third thing I did and the focus of this article was to leverage ANTS Profiler to find areas in my code that required optimizing. I am going to talk about this in some detail to outline my approach to doing this and how this helped with the performance tuning.
Configuring ANTS Profiler to work with SharePoint
To get started, you'll need to have some sort of development box already in place where your code has been deployed to. In my specific example, I had WSS 3.0 installed in a single server scenario, with all of my custom application pages stored in the _layouts directory.
Download and install the ANTS Profiler from here. They offer a free 14-day trial that will be enough to get you going. I really do recommend that any serious SharePoint developer or .NET developer have this tool in their tool belt.
Once the profiler is installed, RedGate has provided us with a really handy guide for setting up SharePoint to work with the profiler: http://www.red-gate.com/support/Knowledgebase/ANTS_Profiler/AP4SharePoint.pdf
I won't say much more on the installation steps for ANTS Profiler as they're pretty straight forward.
Once everything has been installed and configured, you can launch the ANTS Profiler. The following is a screenshot of what my profiler page looks like initially:
The above configuration was copied directly from the pdf I'd mentioned above.
If you're comfortable with the settings, click on Start Profiling to get this going. If you encounter an error similar to the screen shot below, make sure the web site on the port you're trying to profile is stopped. ANTS Profiler needs to be able to launch the site on its own, so you can't have it running while attempting to do this. I run into this now and again when I forget to do that.
Working with ANTS Profiler to track down problem areas
Once the profiler has finished loading, you should now have a default window open to the root of your SharePoint web site.
After this page successfully loads, you'll notice that the profiler has already started gathering data on the initial page load of the SharePoint site. What you'll want to do next is navigate to page you're attempting to optimize. In my example, I type the following:
Hit enter, and the profiler will begin to do its job. Typically I wait for my page to load successfully and then I stop the profiler and begin to do the work of analyzing the results.
As you can see in my screenshot above, I have highlighted the region in the profiler that I want to analyze. If you pay attention when your page loads, you'll get a general idea of where you want to highlight in the time window. Looking at my page above, I can see immediately where the HOT regions are. These are the places I need to pay particular attention to immediately.
To show the source code, I click on the method I'm interested in. In my example, since the slowdown was primarily on Page_Load, that's what I want to drill down into. If I click on theASP._layouts_motorola_not_optimized_aspx.Page_Load method, my screen will refresh with a code view of my page:
The really neat thing about the ANTS Profiler is the way that the scroll bar on the right highlights in RED my problem areas so that I can jump to that part of the code quickly. One of the pieces I was able to optimize was myPopulateDropDownLists method that I had written. Using the profiler I noticed the following bit of code was taking over a second to load:
It would appear that the getDDLNames method, another method I had written, was taking a bit longer than it should to run. Further investigation showed that the reason for this came down to calls to theSPSecurity.RunWithElevatedPrivileges method taking on Page_Load 1.5 seconds to run. Since the SPSecurity.RunWithElevatedPrivileges method is a part of the SharePoint Object Model and not something I had written, I really couldn't optimize that method, I had to come up with a better way to limit the affect it had on my performance.
Within the PopulateDropDownLists method, I was populating a total of 8 drop down controls, each making a call do the getDDLNames method. This was resulting in a huge performance hit simply due to the number of times I was calling SPSecurity.RunWithElevatedPrivileges. I was able to improve the performance of this page by eliminating the getDDLNames method entirely and moving the elevation code up to thePopulateDropDownLists method and making a single call for all 8 drop down lists. As you can see, working with a tool like this makes it really easy to see into areas of your code that you might not have otherwise suspected for the slow down.
I also spent a bit of time going through other areas of my code where this elevation call was being made too many times. I consolidated all areas that required elevation into a single elevation block.
I used the profiler in other areas to optimize code that was not dry enough, and to remove methods that could be architected in better ways. I found that by going through the profiler results and comparing to the code optimization practices found in this document: http://msdn.microsoft.com/en-us/library/bb687949.aspx. I was able to find several areas that needed optimizing.
Take a look at the example below:
SPFieldUserValue user = new SPFieldUserValue(web,Convert.ToString(listItem["Employee"]));
peEmployee.CommaSeparatedAccounts = pmaUser.LookupValue;
If we have a SPFieldUserValue object, calling upon the LookupValue property will return the Name of that user. This is not to be confused with the LoginName property. Assigning that to the CommaSeparatedAccounts property may do the trick and will load that user account into the control but not without a performance hit.
A better approach would be:
SPFieldUserValue user = new SPFieldUserValue(web,Convert.ToString(listItem["Employee"]));
peEmployee.CommaSeparatedAccounts = pmaUser.User.LoginName;
peEmployee.CommaSeparatedAccounts = pmaUser.User.LoginName;
The difference is minor. Instead of using the LookupValue property, we leverage the SPUser object and call upon the LoginName property. In all of my testing, I noticed an improvement in speed when using the LoginNameproperty.
Depending on your environment, the output from either of those properties will differ and that's the heart of the performance issues. In my environment, LoginName and Name outputted the following:
Name - "Joe User"
LoginName - "domain\juser"
Results/Conclusion
Using a combination of all the techniques I've described above, I was able to dramatically reduce the load time of this page and increase performance to the point where users are happy. Going forward, I was able to gain valuable insights into what aspects of the object model take time to load and therefore require careful planning before implementation.
