If the answer to any of these questions is Yes, and you are using the built Umbracos Url rewrite engine (Urlrewriting.Net) with more than a handful of rewrite/redirect rules and then read on-that this blog can solve many of your problems. I should point out at the outset that this post is not intended as a direct criticism of Urlrewriting.Net, just a write-up of my experiences of to distribute hundreds of rewrite/redirect rules.
My company has recently launched a multi-site installation of Umbraco 4.7 and needed a rewrite engine for two main reasons:
Redirect URLs that had been in use for many years at our old CMS, to corresponding pages on our new websites write about certain URLs to make them SEO-friendlyYour choice of rewrite/redirect engine is pretty important. If you believe that the set of rules that you are developing will run for every URL on your site (pages, media files, JavaScript files, stylesheets, Umbraco backoffice ...), then it is a lot of processing.
UrlRewriting.Net is built into Umbraco, as it seemed to be the obvious choice. And we had no problems with it during the build of the system.
We moved progressively more and more content/sites over from our old CMS to Umbraco, add more rewrite/redirect rules in the process. When we reached a point where it was in the region of 600 rules, something obviously wasn't right-but we were not able to pinpoint the cause.
App. pool recycle took over one minute, the server seemed to be tough and we had periods where CPU usage went through the roof, leads to the site that is not responding.
It was while researching the issue that I came across this blog post:
http://blog.kurtschindler.net/post/urlrewritingnet-Performance-Issues
Kurt seemed to be describing our questions exactly.
I did a quick test on my local copy of our Umbraco CMS by simply deleting all the rules from the UrlRewriting. config file and restart IIS. Suddenly, the app pool recycling took a couple of seconds, rather than minutes, and everything seemed almost a lot snappier.
So we decided to choose another rewrite/redirect tool was an urgent requirement.
Advice in Kurt's blog is to try and Helicons ISAPI rewrite. But if you are using IIS 7 or above, there is another (free) alternatives in the form of Microsoft's own IIS Url rewrite 2.0.
You can add the package to IIS, and if you have less than 250 KB of code, you can also edit them through IIS Control Panel GUI.
Migrate the redirection rules from UrlRewriting.Net is pretty self explanatory. In fact, for our site, we have a list of the old vs new URLs in an Excel spreadsheet, and I had written a macro to generate rewrite/redirect rules in XML. So it was just a case of updating the macro to input rules in the IIS rewrite format.
Policies are stored in Web.config itself by default. But you can move them to a separate config file easily enough. I'll cover this in a later blog.
All setup and tested, and the difference seems to be huge-The IIS worker process used to usually use more than 4 GB of RAM. Today, with 700 MB-just by changing the rewrite engine. We also have had no repeat of the events of high CPU usage. So we're pretty happy with our choice of Umbraco and everything in the world is good again-until the next problem fo course.
Hope this helps someone out of a similar dilemma.
No comments:
Post a Comment