Use a stress test tool
For some projects, performance is so critical, and load on the site so significant that performance stress testing will be an important part of the development project. Such tools typically enable testers to record and sometimes script and parameterise realistic user scenarios, then replay these over and over to simulate high levels of user actvity and finally they also can support monitoring and reporting of application performance.
However, it is possible to performance test on a budget. If you have the time to setup and support it, the Java’s open source load generator The Grinder has been ported to .Net. However, without sufficient infrastructure and network bandwidth, you may find that you cannot put sufficient load on your application.
Having used Load Impact on past projects we have found it to be a very cost effective way to load test an Umbraco site. Load Impact offers a freemium model where you can create low load simulations by recording interactions with your Umbraco site, and then replaying up to 100 virtual users for 5 minutes for free. Larger numbers of user and longer durations can either be paid for on a per test basis or per month basis.
Consider options to improve your infrastructure performance
Once you’ve followed the tips in this and earlier articles to improve the performance of your Umbraco site you may find that the easiest way to achieve performance improvements is to improve the performance of your infrastructure.
Do a forklift upgrade of your server
“Complexity is the central enemy of reliability”
Geer et al 2003.
Many of our performance tuning tips require some special configuration or coding to implement the optimisation. This inherently increases the complexity of the site, and so can affect the sites reliability and supportability.
If you find that performance of your site is being bound by the capacity of your webserver (such as memory or cpu capacity), then by far the simplest solution is to increase capacity of the server. Granted this can be challenging when the site is hosted on a traditional dedicated server infrastructure, however on modern cloud based virtualised webservers such forklift upgrades are rediculously trivial.
For example, we have experience of increasing the performance of a client site in minutes using Amazon Elastic Compute Cloud, where a server upgrade simply requires a change of configuration setting and a reboot.
Use a CDN
A Content Delivery Network (CDN) such as Amazon CloudFront enables the static content on your site to be distributed across a network of edge nodes which are physically closer to your site visitors. By moving this static content to a server that is physically closer to visitors, there will be lower network latency and thus reduced page load times. Also by moving the network requests for these static files off of your Umbraco server, you will also reduce load on the server, and enable you to achieve greater performance with the same resources.
Offload the database to a separate server
One other option to consider to improve the performance of an Umbraco website with considerable database usage, is to move the SQL Server database to a separate database server, freeing up capacity on the web tier.
In a number of recent projects we have offloaded the Umbraco database to a seperate database server using Amazon Relational Database Service (RDS).
Remember not all Umbraco websites are database intensive - a simple brochure site with no protected content will use very little database resources.
Consider load balancing - with care
When you’ve moved as much load off the web tier using a CDN and offloaded the database, and taken the performance of a single server to the maximum available capacity then you should look to using a load balanced cluster to introduce additional capacity.
However, while it is perfectly practical to load balance an Umbraco instance it does introduce significant complexity. In a previous project where we were asked to diagnose and debug a load balanced Umbraco instance which was suffering repeated catastrophic failures, we found the culprit being a single poorly written Umbraco plug-in. I mention this up because the problem was caused only because the site was load-balanced and was particularly difficult and thus costly to debug. Load balancing should be carefully considered as a route to increased performance at low costs.