Reputation: 31
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:
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
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