Showing posts with label Umbraco. Show all posts
Showing posts with label Umbraco. Show all posts

Tuesday, March 4, 2014

Why not to use the built in Umbraco Url Rewriting engine

Recently experienced some problems with Umbraco installation?  Maybe a combination of any of the following? Bad performanceErratic CPU usage (including unexplained periods of 100% CPU usage of IIS worker process) high memory usage of IIS worker ProcessSlow app pool recycling times
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-friendly
Your 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.


iPage Reviews: Get $10 Cashback Now

Monday, March 3, 2014

Umbraco on cheap web hosting

So I had a friend who runs a landscape gardening business, and wanted a website to showcase their work-but it needed to be on a budget.

Umbraco put to work here? Yes, the answer is-after a bit of wrestling.

He had already a domain name, so we just bought the regular hosting package from TSOHost (www.tsohost.com/product/Web hosting) at £ 2.99 per month, or £ 34.99 a year.

That buys you the option to run up to 4 websites support ASP.NET 4 and uses MySQL as the backend database (each site can also have multiple domain "aka" pointed at it, so if you're running a multi-site Umbraco installation, you can support more or less as many domains as you want).

Basically the install process was a bit of a nightmare (I chose 4.11.4, later versions may have problems with case sensitivity for MySQL database table names when running on Linux), but I got there in the end.  You must make sure you use the CHMOD (via FTP) to "write" permissions on the appropriate folders. And I had to use the control panel in the cloud to change the application pool to the "isolated" position.  I also noticed these issues:
During installation, you may need to manually recover the app if you notice any odd behavior between the installation steps.When you start working with Umbraco, you may need to recover the app after a change to a template/masterpageI also found that when changing content and publishing, it wasn't showing on the front end until ... you guessed it ... the application pool manually recovered.However, I managed to fix this by changing the setting to "True" in the config/config: umbracosettings.
        True
When the place starts only after a period of inactivity, the app pool starting may take a few seconds, but once up and running, everything seems pretty impressive ... especially for £ 35 per year.  Now all I have to do is finish off the site! Had my first problem today, which was solved effectively by Tsohosts support team within an hour.  Umbracos built-in Url Rewriting does not work (Yes, I know that I blogged about it is unstable, but I just needed a rule to rewrite/sitemap.xml to/sitemap/).

Activate the Umbraco's Url Rewriting, you need to go to the Windows configuration options for your Web site in the cloud, the dashboard, look at the .Net Version page and tick the box next to "Wildcard map for ASP .NET '.


iPage Reviews: Get $10 Cashback Now

When your intrusion prevention system (IPS) prevents your Umbraco CMS from working ...

Had a head-scratcher problems this week.  When you save a document type in Umbraco back-office, Umbraco database were to become damaged (especially items in tables cmsTab and cmsPropertyType).  Some fields (such as alias, name, and description) was inexplicably, set to empty strings.

Any attempt to access the content using the damaged document type in Umbraco back-office led to a server error 500:

Found multiple controls with the same ID "prop". FindControl requires that controls have unique IDs,
the only fix was to manually restore the individual field values struck records, based on a backup copy of the database.

So what could have caused this disaster?

We first blamed the Umbraco-perhaps there was a bug that causes the document type save operation fails.  But no, nothing in the Umbraco log or System event log.

Then I remembered that our IT Department had recently installed a Cisco ASA 5515 Intrusion Prevention System (IPS), firewall, "in front" of the web-server.  Hmmm ... would this system, in order to prevent problems, actually cause harm?  The answer seems to be "Yes".

As far as I can tell, it seems that if you RECORD data that contain the word "Select" followed somewhere in the request data using the word "from", Cisco IPS assume you try a SQL injection attack (Yes really!).  Of course, there are many times when you write these words legitimate (for example, "Please Select a logo from this list").

Anyway, the IPS appear to be partially blocks or truncate the client request, so the server got unexpected data. Umbraco  Seems that no validation is done on the server side to verify that the client has given a name or alias for each document type property, so empty strings are stored in the database, hence the problem.

Work around?

Install an SSL certificate on the server, and do your editing via HTTPS (undecipherable by IPS).  This is probably good though.If possible, perform for editing document types using a remote desktop connection directly to the server (using the fjärrskrivbordssessionens browser and http://localhost/umbraco/, to avoid the IPS).Use a tool like uSiteBuilder to synchronize your document type and template changes with a Visual Studio project, instead of using the Umbraco back-office.
With 20 years of experience in it, I have a carefully honed believe that well-intentioned security software and systems can often cause more problems than they are meant to prevent.

The reason for writing posts in this blog, it is hoped that one day someone will suffer the same problems and stumble across this solution via Google.  So, I hope it helped you.


iPage Reviews: Get $10 Cashback Now