Initialization of IIS applications in Azure shows 500 periodically after deployment Upgrade

I recently implemented Application Initialization in one of our Azure projects to minimize the time it takes for each site to warm up.

I, in fact, implemented almost all the steps described in this blog post .

In the new deployment, it works for all 10 of my sites in IIS. The problem is that when I then try and update this deployment, I get 500 errors for the first 25 requests or so for each site .

Now this is not ideal, because instead of hitting each site once to warm up after deployment, I now have to load each site about 25 times before I can overcome the 500s. They do not stop there, but it seems that they happen sporadically.

If I repeat the image after deployment, this fixes the problem. However, at the cost of downtime, which is not an option.

Any ideas?

I have the following:

Run the task in ServiceDefinition.csdef to enable the application initialization module:

<Task commandLine="enableApplicationInitializationIIS.cmd" executionContext="elevated"></Task> 

Then inside this task I:

 PKGMGR.EXE /iu:IIS-ApplicationInit 

In ServiceConfiguration.csfg, I installed the latest osFamily :

 <ServiceConfiguration serviceName="Foo" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="3" osVersion="*" schemaVersion="2012-10.1.8"> 

Then, in the Web role, I have the following to enable all the necessary application initialization parameters:

 public class WebRole : RoleEntryPoint { public override bool OnStart() { using (var serverManager = new ServerManager()) { foreach (var site in serverManager.Sites) { foreach (var application in site.Applications) { application["preloadEnabled"] = true; } site.ServerAutoStart = true; } serverManager.ApplicationPoolDefaults.ProcessModel.IdleTimeout = new TimeSpan(00, 00, 00); serverManager.ApplicationPoolDefaults.Recycling.PeriodicRestart.Time = new TimeSpan(00, 00, 00); serverManager.ApplicationPoolDefaults["startMode"] = "AlwaysRunning"; foreach (var appPool in serverManager.ApplicationPools) { appPool["startMode"] = "AlwaysRunning"; } serverManager.CommitChanges(); } return true; } } 

And finally, each of my sites has the following:

 <system.webServer> <applicationInitialization skipManagedModules="true"> <add initializationPage="/" /> </applicationInitialization> </system.webServer> 

Not sure what skipManagedModules ?

+4
source share
1 answer

I had a similar problem and you found your post. In my case, this problem was already there with the initial deployment, as well as with the deployment of the update.

In my error logs, I found that the exception "Value cannot be null." It seems that ServerManager was unable to initialize - the code inside the using statement was not executed. It turned out I tried to deploy the Microsoft.Web.Administration assembly (from Windows 7) to a Windows Server 2012 machine.

After applying the correct version, the 500 errors disappeared.

 System.TypeInitializationException: The type initializer for 'Microsoft.Web.Administration.ConfigurationManager' threw an exception. System.ArgumentNullException: Value cannot be null. at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at Microsoft.Web.Administration.ConfigurationManager..cctor() --- End of inner exception stack trace --- at Microsoft.Web.Administration.ConfigurationManager..ctor(ServerManager owner, String applicationHostConfigurationPath) at Microsoft.Web.Administration.ServerManager..ctor(String applicationHostConfigurationPath) 

EDIT:

I continued to experience 500 initialization errors, and it seems that this is due to two tags:

 <applicationInitialization remapManagedRequestsTo="app_starting.htm" skipManagedModules="true" > <add initializationPage="/" /> </applicationInitialization> 

Removing the remapManagedRequestsTo and skipManagedModules attributes seems to fix 500 errors, see Initializing IIS 7.5 Applications for the ASP.NET Web Service (Warm Up) without Reassigning Requests .

+2
source

Source: https://habr.com/ru/post/1481331/


All Articles