Last post Aug 05, 2010 11:53 AM by hitchhiker999
Jul 27, 2010 04:41 AM|onyxmaster|LINK
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
Aug 05, 2010 06:12 AM|hitchhiker999|LINK
Did you manage to solve this? I've got a similarly high-load website and am mid-way upgrading to v4...
Aug 05, 2010 11:03 AM|onyxmaster|LINK
Not yet, I've posted the problem to MS Connect:
If you aren't using precompilation it works just fine.
Aug 05, 2010 11:53 AM|hitchhiker999|LINK
As I said I have a high-volume website, approx 100 requests per second, i use precomp + merge. I've staved off the upgrade, I just can't risk having that kind of issue on a production server. Probably best to wait 6 months, and let the packs / updates /
google info develop.