Experienced any issues with your Umbraco installation recently? Maybe a combination of any of the following?
If the answer to any of these questions is yes, and you are using Umbraco's built in Url rewrite engine (Urlrewriting.Net) with more than a handful of rewrite/redirect rules, then read on - as this blog might solve a lot of your problems. I should point out from the outset that this post isn't intended as a direct criticism of Urlrewriting.Net, just a write-up of my experiences of using it to deploy hundreds of rewrite/redirect rules.
My company has recently launched a large multi-site installation of Umbraco 4.7, and needed a rewrite engine for two main reasons:
Your choice of rewrite/redirect engine is quite important. If you consider that the set of rules you develop will be run for every Url on your site (pages, media items, JavaScript files, style sheets, Umbraco backoffice...), then that's a lot of processing.
UrlRewriting.Net is built in to Umbraco, so it seemed to be the obvious choice. And we had no problems with it during the build of the system.
We gradually migrated more and more content/sites over from our old CMS to Umbraco, adding more rewrite/redirect rules in the process. When we reached the point where there were in the region of 600 rules, something clearly wasn't right - but we couldn't put our finger on the cause.
App pool recycles were taking over a minute, the server seemed to be running slow, and we were experiencing periods where the CPU usage went through the roof, leading to the site being unresponsive.
It was when researching the issue I came across this Blog post:
http://blog.kurtschindler.net/post/urlrewritingnet-performance-issues
(Note: above link seems to be dead, but here it is from archive.org - https://web.archive.org/web/20150507212512/http://blog.kurtschindler.net/urlrewritingnet-performance-issues/ )
Kurt seemed to be describing our issues exactly.
I did a quick test on my local copy of our Umbraco CMS by simply removing all the rules from the UrlRewriting.config file, and restarting IIS. Suddenly, app pool recycles were taking a couple of seconds, rather than nearly a minute, and everything seemed a lot snappier.
So we decided that choosing a different rewrite/redirect tool was an urgent requirement.
The advice in Kurt's Blog is to try Helicon’s ISAPI Rewrite. However, if you're using IIS 7 or above, there is another (free) alternative in the form of Microsoft's own IIS Url Rewrite 2.0.
You can add this package to IIS, and if you have less than 250Kb of rules, you can even edit them via IIS Control Panel GUI.
Migrating the redirection rules from UrlRewriting.Net is fairly straightforward. In fact, in the case of our site, we have a list of the old vs new Urls in an Excel spreadsheet, and I had written a macro to generate the rewrite/redirect rules in XML. So it was just a case of updating the macro to output the rules in the IIS Url Rewrite format.
Rules are stored in web.config itself by default. However, you can shift them in to a separate config file easily enough. I'll cover this in a later Blog.
Everything setup and tested, and the difference seems to be immense - The IIS Worker Process used to commonly use well over 4Gb of RAM. Today, its using 700Mb - just by changing rewrite engines. We've also had no repeat of the high CPU usage events. So we're fairly happy with our choice of Umbraco, and everything in the World is well again - until the next problem fo course.
Hoping this helps someone out of a similar dilemma.
- Poor performance
- Erratic CPU usage (including inexplicable periods of 100% CPU usage by the IIS Worker Process)
- High memory usage by the IIS Worker Process
- Slow app pool recycle times
If the answer to any of these questions is yes, and you are using Umbraco's built in Url rewrite engine (Urlrewriting.Net) with more than a handful of rewrite/redirect rules, then read on - as this blog might solve a lot of your problems. I should point out from the outset that this post isn't intended as a direct criticism of Urlrewriting.Net, just a write-up of my experiences of using it to deploy hundreds of rewrite/redirect rules.
My company has recently launched a large multi-site installation of Umbraco 4.7, and needed a rewrite engine for two main reasons:
- Redirecting the Urls that had been in use for many years on our old CMS, to the equivalent pages on our new website(s)
- Rewriting certain Urls to make them SEO friendly
Your choice of rewrite/redirect engine is quite important. If you consider that the set of rules you develop will be run for every Url on your site (pages, media items, JavaScript files, style sheets, Umbraco backoffice...), then that's a lot of processing.
UrlRewriting.Net is built in to Umbraco, so it seemed to be the obvious choice. And we had no problems with it during the build of the system.
We gradually migrated more and more content/sites over from our old CMS to Umbraco, adding more rewrite/redirect rules in the process. When we reached the point where there were in the region of 600 rules, something clearly wasn't right - but we couldn't put our finger on the cause.
App pool recycles were taking over a minute, the server seemed to be running slow, and we were experiencing periods where the CPU usage went through the roof, leading to the site being unresponsive.
It was when researching the issue I came across this Blog post:
http://blog.kurtschindler.net/post/urlrewritingnet-performance-issues
(Note: above link seems to be dead, but here it is from archive.org - https://web.archive.org/web/20150507212512/http://blog.kurtschindler.net/urlrewritingnet-performance-issues/ )
Kurt seemed to be describing our issues exactly.
I did a quick test on my local copy of our Umbraco CMS by simply removing all the rules from the UrlRewriting.config file, and restarting IIS. Suddenly, app pool recycles were taking a couple of seconds, rather than nearly a minute, and everything seemed a lot snappier.
So we decided that choosing a different rewrite/redirect tool was an urgent requirement.
The advice in Kurt's Blog is to try Helicon’s ISAPI Rewrite. However, if you're using IIS 7 or above, there is another (free) alternative in the form of Microsoft's own IIS Url Rewrite 2.0.
You can add this package to IIS, and if you have less than 250Kb of rules, you can even edit them via IIS Control Panel GUI.
Migrating the redirection rules from UrlRewriting.Net is fairly straightforward. In fact, in the case of our site, we have a list of the old vs new Urls in an Excel spreadsheet, and I had written a macro to generate the rewrite/redirect rules in XML. So it was just a case of updating the macro to output the rules in the IIS Url Rewrite format.
Rules are stored in web.config itself by default. However, you can shift them in to a separate config file easily enough. I'll cover this in a later Blog.
Everything setup and tested, and the difference seems to be immense - The IIS Worker Process used to commonly use well over 4Gb of RAM. Today, its using 700Mb - just by changing rewrite engines. We've also had no repeat of the high CPU usage events. So we're fairly happy with our choice of Umbraco, and everything in the World is well again - until the next problem fo course.
Hoping this helps someone out of a similar dilemma.
Just came across this comment. I think I'll do some "premature optimisation" on this new site and move the handful of rules from urlrewriting.config now before I turn it live... Thanks!
ReplyDeleteThe problem is regex pattern matching. Convert to IIS Rewrite. http://i.imgur.com/o64EBzU.png?1
ReplyDeleteHow do you change the module umbraco uses from using urlRewriting.net to using the 'built in' IIS Rewrite 2.0?
ReplyDeleteFor us, we simply stopped using the rewrite rules in the Umbraco config file (remove the rules from the config file and here's no overhead involved - or so it seems), and instead install and use IIS Rewrite (which is an add-on for IIS directly, and not related to Umbraco specifically). Although the config data is XML in both cases and looks similar, the re-write rules are in a different format, so you need to review/edit the logic of each of your rules.
ReplyDeleteis there a sample code on how to stop using rewrite rules? I am kind a beginner with Umbraco
ReplyDeleteYou just need to convert your rules to IIS Url Rewrite format instead (you also need to add the IIS Url Rewrite add-on to IIS). The format of the rules aren't quite the same, but are similar (IIS Url Rewrite is more powerful).
Delete@Steve - We have a large number of sites under a single Umbraco instance. Many of those have www and non-www equivalents and we want to create a rule that redirects all of the www incoming request to the non-www equivalent. This amounts to about 5,000 page reequests per day per Google analytics. Would this be equivalent to having numerous rules. In other words, does a high volume traffic and incomng requests accociated with a single rule in urlRewriting.net function the same was a having let's say 1,000 rules which only affect a couple of pages.
ReplyDeleteThe performance problem is related to the number of individual rules that you have in your UrlRewriting.config file, and not so much the amount of traffic you receive. We have a number of rules (using IIS Url Rewrite) which do precisely what you want - i.e. any requests for site.com get redirected to www.site.com
DeleteThis sort of thing:
<rule name="domainredirect" patternSyntax="Wildcard">
<match url="*" />
<conditions>
<add input="{HTTP_HOST}" pattern="site.com" />
</conditions>
<action type="Redirect" url="http://www.site.com/{R:0}" logRewrittenUrl="true" />
</rule>
@Steve - What is the difference between the Umbraco 301 URL Tracker vs Urlrewriting.Net? Does Umbraco 301 URL Tracker write to the web.config file. Is is a more robust solution than Urlrewriting.Net? It's obvously easier to use this than IIS Url Rewrite 2.0 which requires you to go into the IIS. Thoughts
ReplyDelete301 URL Tracker is a package that remembers all the old Urls you had in Umbraco (prior to changing the name of a page, or moving it somewhere else). e.g. if you use the Umbraco back office to rename your "about" page to instead be "about-us", it makes sure that site.com/about/ gets redirected to site.com/about-us/ automatically. It stores it's data in the Umbraco database.
DeleteThanks Steve for your reponses. Is 301 URL Tracker useful as a complement to IIS Url Rewrite 2.0? In the example above, would the chidren - example site.com/about/child_1 get redirected to site.com/about-us/child_1. 301 URL Tracker, if it doesn't impose a lot of overhead or having perfomance problems similar to Urlrewriting.Net, might be useful. Do you forsee a use for both 301 URL Tracker in conjunction with IIS Url Rewrite 2.0? What woud be the division of labor between them?
DeleteNote: http://blog.kurtschindler.net/post/urlrewritingnet-performance-issues is no longer a valid link in that it points to a non-desrcipt page.
ReplyDeletenice
ReplyDelete