[AspNetCoreModule] consider an 'auto-start' option

[Tratcher]

From @tuespetre on May 2, 2016 21:1

With a 'traditional' ASP.NET application, IIS could be configured to have the app pool "Always Running", which would trigger Application_Start or a Startup class, giving developers a chance to schedule recurring background tasks and trust that they ran as long as IIS and the app pool were running. This was great for simple, small-scale deployment scenarios.

HttpPlatformHandler was not as friendly and enabling for such scenarios. Now that HttpPlatformHandler has been forked to AspNetCoreModule, could an option be added that causes the module to start the application immediately instead of waiting for a request?

Copied from original issue: aspnet/IISIntegration#161

[Tratcher]

From @mikes-gh on May 12, 2016 8:2

Shouldn't the application lifetime be controlled at the IIS app pool level as it is now?

[Tratcher]

From @guardrex on May 12, 2016 15:54

@mikes-gh It is, @tuespetre is calling attention to the startup nature of the app. Take a Windows Service, for example. When you start that service and set it to automatically start, you know that your service is going to fire right up and always run when the server restarts. We don't have that for IIS apps, and I think this is a great idea.

[Tratcher]

From @mikes-gh on May 12, 2016 16:38

@guardrex Being devils advocate 😄 I'm not sure web.config could control the app pool process lifetime variables such as "Always Running" ? The app pool might have more than one app in which case you might have 2 settings fighting each other. Unless we change the model to one app pol per app.
If @tuespetre is saying lets replace Application Initialization with a new mechanism in AspnetcoreModule I whole heartily agree. Its a real pain at the mo and pretty much every app I write I want always running and warmed up by default.

[Tratcher]

From @guardrex on May 12, 2016 16:58

@mikes-gh AFAIK that's a non-starter b/c they issued earlier guidance: one app for one AppPool ... but that may have changed. I don't recall a more recent discussion on it.

I wasn't really too concerned about web.config setting it up; although, I believe you can set Idle Time-out with the <processModel> and the Always Running with applicationInitialization in web.config, but I've never done it. If I could just set things up manually, I'd be happy.

I want always running and warmed up by default.

👍

[Tratcher]

We plan to use this feature to replace the DEBUG request (#102) VS currently sends to start the process. When that happens remove the DEBUG filter from IISMiddleware.

[sergioadh]

Is there any updates on this feature? All the applications we have developed need to be ready when they are called, without waming up it first calls are painfully slow. And since the application lifetime is not really managed by IIS (only the application pool lifetime which doesn't impact the app at all) then we have no control of when the application goes down and up again.

[ghord]

Note that background job runners such as Hangfire have no way to properly work on IIS under .Net Core because of missing IProcessHostPreloadClient support.

[snowyowlapps]

Anyone have an update on this?

[tuespetre]

Funny you post just now, I cloned a bit ago to have a crack at it 💥

[tuespetre]

Eh, so it turns out setting AlwaysRunning and enabling preload works out well enough for us. I'm not going to do anything else with this.

[neumartin]

@tuespetre can you tell me how to enable preload?
Thanks!

[sergioadh]

@tuespetre Could you elaborate? We happen to see that even with AlwaysRunning and enabling preload the application is not ready when calling it and causes slow first time requests.

[pan-wang]

Autostart requires fundermental change of current ANCM design which loads configuration and then start Kestrel only after the first request hit it. Will investigate the possibility in the future. Sent from ZTE's mobile email On 2017-02-09 10:38 , sergioadh<mailto:notifications@github.com> Wrote: @tuespetre<https://github.com/tuespetre> Could you elaborate? We happen to see that even with AlwaysRunning and enabling preload the application is not ready when calling it and causes slow first time requests. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#29 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ARVK272X05g-n7dfSLp6MAjE8oHpRt-Xks5ra10egaJpZM4Kis1d>.

[wc-matteo]

What's the time interval after which Kestrel unloads when no requests are received? Is it always the same? Can it be configured?

...or is it that after the first request, as long as the app pool is running, Kestrel runs indefinitely?

[mikes-gh]

Kestrel doesn't unload itself IIS w3wp.exe process does that.

The best I have come up with is this in my applicationhost.config (dont edit this unless you know what you are doing).

            <add name="cardpayments" autoStart="true" managedRuntimeVersion="" startMode="AlwaysRunning">
                <processModel idleTimeout="00:00:00" />
            </add>

This avoids the application having to load on first request and stops it unloading but it doesn't warn it up.
For that you can have a warm-up URL that does for example a database query which warms up all the entity core stuff. Then you need to use application inialization

https://www.iis.net/downloads/microsoft/application-initialization

In IIS 7.5 the experience is not great and there is some hand editing of files. I beleive IIS 8 has better UI for this stuff.

[wc-matteo]

Thanks for the answer @mikes-gh. Right, I forgot... Kestrel has no process management capabilities, those are in the upper layer (e.g. IIS).

So, to recap: with idletimeout 0 and with no app pool recycling on (i.e. as long as the worker process is alive), the app stays responsive.

Regarding the warm-up, starting with IIS 8 Application Initialization is bulit-in (setting: preloadEnabled). I remember having some issues making it work with ASP.NET Core, though...

[emirhosseini]

@mikes-gh That doesn't appear to be true. We have all the proper settings in IIS (idle timeout disabled, always running turned on, etc.) and I still see logs that say "Application 'MACHINE/WEBROOT/APPHOST/ApplicationName' started process '3380' successfully and is listening on port '13321'.".

So it appears that even though all the settings in IIS for the app pool and the site are to keep the site alive, after some inactivity the log entry above originating from "IIS AspNetCore Module" is indicating that it is starting up as if it was stopped. We're having an issue where this is too slow (about 6 seconds) and we're under tight time constraints. @pan-wang seemed to indicate this is a known issue since he said they can't enable autostart for Kestrel itself.

[mikes-gh]

@emirhosseini did you make sure your idle timeout is 0. I seem to remember idle timeout didn't seem to respect the always running param

[emirhosseini]

@mikes-gh Yes Idle timeout is 0. I've already gone through all the IIS related usual suspects. If you Google this you will see people saying the same thing. Regardless of IIS settings, Kestrel seems to terminate and I see the log entry I mentioned above every few hours starting up the asp.net core server on a different port each time (since I don't have a set port to use).

According to the docs, Kesterl is supposed to terminate due to crashes but I see no crashes in the event logs so not sure why it's terminating. Others suggest to ping the app every minute or so to force it to stay alive which is what I'm forced to do at this point.

[mikes-gh]

You're right I just tested a site that has not been accessed for a while and it took 10 secs to get to home page.

I don't suppose you have the option to run on nginx/linux
My app runs there now (you can connect to sql server form linux in netcore).
I don't have any of these issues on that site.

[emirhosseini]

@mikes-gh Unfortunately that's not an option for a few reasons in my case. Regardless it doesn't seem to me like IIS is what's causing this. It looks like Kestrel is going offline after some inactivity. We have other non core sites in IIS that have not had this issue with the same IIS settings to stay alive.

[sergioadh]

@emirhosseini we've experienced the same thing, still waiting for a fix or a feature implementation. We have resorted to making a request to our services/pages to avoid them going down.

[emirhosseini]

@sergioadh That's good to know because it confirms what I'm seeing. I'm going to do the same thing. On what interval are you hitting your service to keep it alive?

[sergioadh]

It's been a hit and miss, we don't want it to be hit too many times just by this scheduled task but there's no guarantee when the Kestrel server goes down, sometimes it goes down really quick, sometimes it takes a little longer. We started at 5 minutes but saw it was inconsistent, if I'm not mistaken we have it to 1-2 minutes. This is faaar from a fix/workaround though, it just feels too sloppy.

[emirhosseini]

@sergioadh Wow that's good to know! Yea it's really disappointing that they assumed no one would need to have a service that needs to be up at all times. The several second delay to start Kestrel back up periodically is simply unacceptable. It goes to show how much dotnet core is really NOT production ready.

[los93sol]

Any updates on auto start functionality?

[matt-psaltis]

There's currently lots of contradicting information around this. I've got a dotnet core 2.0, Kestrel based app hosted in an Azure App Service. It's Nov 2017 - Does applicationInitialization and/or <applicationPools><add autoStart="true" startMode="AlwaysRunning" /> correctly start the dotnet.exe process after a deployment or app pool restart? Is the always on heart beat the only method currently working (excluding webjobs etc)?

Cheers.

[matt-psaltis]

Also, just in case it changes things - happy to run preview bits 2.1 etc :)

[thj-dk]

Any updates on this? It's truly a must have feature...

[KLuuKer]

@Tratcher can we please get a milestone on this issue?

[Tratcher]

@shirhatti

[pan-wang]

I will do some investigation on the possibility

[muratg]

@pan-wang @shirhatti closing this one. @shirhatti will file another bug to see if this just works in in-proc case.

[carlowahlstedt]

@muratg @shirhatti can we get the linked bug # here?

[shirhatti]

https://github.com/aspnet/IISIntegration/issues/507