User-177209433 posted
Hello!
We used ASP.NET precompilation (first manually, then with VS2008 WDP) with .NET 3.5 almost (see below) successfully.
After we moved to 4.0, the precompilation no longer works properly. The precompilation process itself succeeds, and the website works, but it consumes about twice the CPU it does without any precompilation. We use non-updatable precompilation (so webpages
get compiled completely).
Our internal profiling tells us that most of the threads spend their time within variations of the following stack:
...
System.Web.dll!System.Web.Compilation.BuildManager.GetVPathBuildResultFromCacheInternal(System.Web.VirtualPath virtualPath, bool ensureIsUpToDate) + 0xa2 bytes
System.Web.dll!System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(System.Web.VirtualPath virtualPath, bool noBuild, bool allowCrossApp, bool allowBuildInPrecompile, bool throwIfNotFound, bool ensureIsUpToDate) + 0x5b bytes
System.Web.dll!System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(System.Web.HttpContext context, System.Web.VirtualPath virtualPath, bool noBuild, bool allowCrossApp, bool allowBuildInPrecompile, bool throwIfNotFound, bool ensureIsUpToDate)
+ 0xcb bytes
System.Web.dll!System.Web.Compilation.BuildManager.GetVPathBuildResult(System.Web.HttpContext context, System.Web.VirtualPath virtualPath, bool noBuild, bool allowCrossApp, bool allowBuildInPrecompile, bool ensureIsUpToDate) + 0x87 bytes
...
It appears that master page (and possibly controls) internal caching is broken in precompiled web sites, leading to reloading of master pages and from precompiled assemblies.
We really would like to use precompilation to enjoy smoother deployments, but since this is a high-load (hundreds of managed requests per second) website and going from 40-50% overall CPU per 8-core machine to 90+% CPU on the same machine is unacceptable.
Also, VS2010 WDP still does not preserve empty directories that contained only controls and master pages in the original projects, leading to loads of "Failed to start monitoring" exceptions when output caching is enabled for any page
that contains precompiled controls (these exceptions are handled internally, but still incur a performance penalty). Since we had this problem in 3.5 also, we continued to use our MSBuild code that created empty directories for controls
and master pages. This removes the exceptions, but I doubt that generating an exception for each control that is being used in a page with enabled output caching is acceptable performance-wise (exception stack trace below).
> System.Web.dll!System.Web.Caching.CacheDependency.Init(bool isPublic, string[] filenamesArg, string[] cachekeysArg, System.Web.Caching.CacheDependency dependency, System.DateTime utcStart) + 0xb0c bytes
System.Web.dll!System.Web.Hosting.MapPathBasedVirtualPathProvider.GetCacheDependency(string virtualPath, System.Collections.IEnumerable virtualPathDependencies, System.DateTime utcStart) + 0x1aa bytes
System.Web.dll!System.Web.ResponseDependencyList.CreateCacheDependency(System.Web.CacheDependencyType dependencyType, System.Web.Caching.CacheDependency dependency) + 0x244 bytes
System.Web.dll!System.Web.HttpResponse.CreateCacheDependencyForResponse() + 0x57 bytes
System.Web.dll!System.Web.Caching.OutputCacheModule.OnLeave(object source, System.EventArgs eventArgs) + 0x708 bytes
