Tuesday, July 27, 2010

Umbraco: Resolving the “Opening edit screen is very slow when macros are present” issue

On our shared Umbraco development server, we were having some performance issues with the backend that neither I nor the other developer on the project were experiencing with the same code/document types/macros on our local system.  Even backing up the shared system and restoring to our local machines didn’t reproduce the problem.  When we’d open up certain pages for editing, it would take a *very* long time for the server to send back the editContent.aspx page (about 35s as measured by Firebug).  Other pages didn’t have the issue. A quick comparison of the pages showed one obvious difference – the slow page had a macro in a content block, the fast page didn’t.  After checking a few things (umbracoLog table in the DB, CPU usage), it was obvious the server wasn’t pegging it’s CPU or anything like that, and the SQL Server process wasn’t going crazy either (which might indicate an excessive number of queries running), so on a whim, I thought I’d dig into the code and see what happens before that “No macro content available for WYSIWYG editing” message is generated.

Now, I could just download the source code for Umbraco and dig in a bit, but I started my investigation on my evening train ride home, where I don’t have Internet access, and I didn’t already have a copy of the code on my machine.  So, I pulled up the secret weapon of a .Net developer’s arsenal, Reflector.  After a search for the message above, I was led to umbraco.macro.MacroContentByHttp, which uses Request.ServerVariables[“SERVER_NAME”] to find out it’s name and makes a request to /macroResultWrapper.aspx to get the contents of the macro:


Could this be our culprit?  I logged onto the server and tried to access the site via the name we were using.  Sure enough, timeout…  So I try pinging the hostname we’re using from the server itself – same result – no response.  I added a host entry for that name using as the IP address, tried hitting the server again from the browser, and sure enough, success.  I cycled IIS, loaded up the backend of the shared dev environment from my client machine, and went to edit a page with a macro – 3 seconds to load. Much better.  Apparently, due to firewall issues on our hosting environment, the server can’t access itself via it’s ‘public’ IP, only via the private IP, but DNS still resolves it’s name to the public IP.

The lesson here: with Umbraco, make sure your server can reach itself using the name you’re using to access it.  Ie. if you use a hosts entry to map myshareddevserver.local to the IP address of your shared dev server in the office and set up an Umbraco instance in IIS on that server, make sure you put the same hosts entry on the dev server too, or you’ll have (at least) this issue.

Note: this may be changed/resolved in Umbraco 4.5 (released last month) – I haven’t worked with that version yet.