The day Umbraco UrlRewriting ruined my anniversary

A site I was building was finished, the client was happy for it to go live and I was preparing the site ready to flick the switch. Coincidently this was my anniversary, and I was looking forward to a nice meal out to celebrate. I knew that the site was running well, I'd had two days to prepare the server and everyone was in agreement that everything was ok to go. Even though the client mandated a launch time after work hours, highly discouraged by us obviously, we were confident that all I needed to do was put the 301 redirects in place, the final stage in our deployment plan.

Now this site had quite a few redirects, roughly 2500, and I thought I'd use the rewriter built into Umbraco; adding that many rewrites using UrlRewrite 2.0 can cause a problem as the Web.config can swell in size forcing you to change a registry setting. So I made a little tool to automate this, taking their csv as input and producing the keys for the config, and put them in. The redirects seemed to working and we were good to go live.

Fast foward a few hours and I received a message from the front end developer on the project, "If you want to enjoy your evening, don't look at the site". Meal, evening and night ruined.

The symptoms

 To say the site was performing like a dog was an understatement; the memory usage kept creeping up and the processor was running at 100%, that was until the app pool would fall over and die, restart and replay the whole sorry story over and over again, almost 4 times an hour. Our infrastructure guru, doubled the rescources of the server and even though it was still fragile, the site made it through the night, just.

Finding the cure

Morning arrived, and we would now have to deal with the fall out. I went in early to try and isolate what could possibly cause this. I had my own data layer, a wrapper on top of uSiteBuilder, could this be causing the issues? I ran some profiling, it was sightly slower than just raw Umbraco, but absolutely not the cause of the program. I had some heavy caching being used to, but again this was not the problem. We had a meeting to try and bang some heads together and find the solution. What had changed since UAT, when the site was performing well? 301 redirects.

Fixing the site

Our server guru quickly removed these 2500 redirects from the site and restarted the worker process. RAM usage and CPU time plumeted, the site was working fine.

Over the day we converted these Umbraco redirects to use Microsoft IIS Rewrite 2.0, and although we did need to change registry sections and reboot the server (not exactly ideal on a live site!) it seemed to work well, very quick and lean on resources. 

Conclusion

The UrlRewriting module built into Umbraco is great if you understand its limitations, I use it on this site for about 10-15 rules. For larger sites though, with a lot of redirects, you need to consider performance and test them much earlier, maybe using Helicon or URL Rewrite. This experience has taught us a lesson; from now on we will be getting the client to provide their redirects much earlier and we will test performance as part of our QA process.

It will be interesting to hear if anyone else has come up against this problem before, and at what number consideration is required.

Comments

comments powered by Disqus