Ian Grieve
Ian Grieve

Reputation: 31

Umbraco 7.6.3 backend is slow after installing Forms 6.0.1 with App_Data virtual directory

We've noticed that after installing Forms 6.0.1 on Umbraco 7.6.3 and using a virtual directory for App_Data causes the CMS to run extremely slow. Some of our clients have load-balanced live environments and have created virtual directories for App_Data, media etc. We’ve upgraded their site from version 4.8.0 to 7.6.3 and after installing Forms and deploying to a demo environment noticed that the CMS was taking forever to do anything. We’ve been using a virtual directory for App_Data on various versions of Umbraco for years and never encountered any issues with this approach.

To eliminate that the issue wasn’t due to anything in the upgrade we were able to recreate the problem following these steps:

  1. On a local dev machine installed a new (clean version) of Umbraco 7.6.3.
  2. Setup localhost using IIS to access the site (rather than IIS express).
  3. Created a virtual directory in IIS for App_Data, pointing to a folder outside of the web root for the solution.
  4. The page load time in the CMS averages approx. 750ms at this point.
  5. Installed Forms via the back-office.
  6. The page load time in the CMS once Forms has installed dramatically increases averaging 21 seconds.

If we remove the virtual directory from IIS or setting fcnmode=”disabled” in web.config the CMS is performant again. From what I’ve read setting fcnmode to disabled will stop file change notifaction, but a downside to this is that the application pool won’t be recycled. This may be something we have to live with but I’m curious what Forms is doing under the hood that would cause this? Forms was previously added to the App_Plugin folder rather than App_Data, was there a reason for this?

The Umbraco Log dramatically increases in file size and contains the following:

2017-06-27 09:37:12,192 [P23168/D99/T80] INFO Umbraco.Core.UmbracoApplicationBase - Application shutdown. Details: ConfigurationChange

_shutDownMessage=CONFIG change
HostingEnvironment initiated shutdown
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
CONFIG change
HostingEnvironment caused shutdown

_shutDownStack= at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal()
at System.Web.Hosting.HostingEnvironment.InitiateShutdownWithoutDemand()
at System.Web.HttpRuntime.ShutdownAppDomain(String stackTrace)
at System.Web.Configuration.HttpConfigurationSystem.OnConfigurationChanged(Object sender, InternalConfigEventArgs e)
at System.Configuration.Internal.InternalConfigRoot.OnConfigChanged(InternalConfigEventArgs e)
at System.Configuration.BaseConfigurationRecord.OnStreamChanged(String streamname)
at System.Web.DirectoryMonitor.FireNotifications()
at System.Web.Util.WorkItem.CallCallbackWithAssert(WorkItemCallback callback)
at System.Web.Util.WorkItem.OnQueueUserWorkItemCompletion(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()

Upvotes: 2

Views: 370

Answers (1)

Myster
Myster

Reputation: 18104

I believe the issue is that this file is being read from the physical path instead of the virtual path. \App_Data\TEMP\formsupdate

If you include this file in both physical and virtual locations this should work around the issue.

I've reported the issue here: http://issues.umbraco.org/issue/CON-1456

Upvotes: 1

Related Questions