This article is part of a series on Performance Tuning Umbraco -- Part 1 | Part 2 | Part 3

Last week we started a series of posts about performance tuning Umbraco sites, where we discussed Image Optimisation, Client Dependency Framework, Mini-Profiler and implementing caching.  In this article we’ll look at the relative performance of @Html.RenderTemplate and @Html.Partial, and also look at database profiling and tuning.

Consider using @Html.Partial() rather than @Html.RenderTemplate

In a previous Umbraco project we had a scenario where we had a shop page and needed to iterate over a collection of products, data of which were stored as nodes. On the product listing page, we chose to render an alternate template for each product the snippet of product information was shown on the listing.

Calling the @Html.RenderTemplate Umbraco method has a lot of overhead when it is called, having a lot of under the hood Umbraco magic being executed. This would be fine for one View on the initial page load, but calling the method 20 times for each product, introduced an unacceptable load time.

The way we solved this was to create a simple POCO model that represented our product node. The model was populated with data from the node, which was then passed into the View. By using the the default MVC @Html.Partial(“ListProductItem.cshtml”,product) method we bypass the under-the-hood Umbraco magic that we simply didn’t need which consequently reduced load times.

Use database tracing tools to find weaknesses in the application layer

Sometimes you will find that a piece of SQL you’ve written in your custom Umbraco code is causing a large amount of load on your database.  

On one of our long running client sites recently we moved the database to run on Amazon RDS to implement database mirroring easily.  However, in doing so we discovered that the database was coming under a large amount of strain even though the application server was under light load.  We used a SQL tracing tool (Express Profiler) to get under the hood and see what queries were running on the database.  This showed that we were flooding the database with calls from the Umbraco Membership feature.  Which helped us to simplify and optimise our application code.

Thats it for this week, next week we’ll look at stress testing and load testing tools.