Process specified by 'processPath' gets killed after some timeout

[pxdeveloper]

I was wondering why the process specified by 'processPath' always got killed when there were no incoming requests for a long period of time. My first thoughts were that the app crashed, but then I monitored it for silent process exits using 'GFlags.exe' and realized that it was the 'w3wp.exe' who killed the process. Annoying is when the next request arrives, it takes up to 4 seconds for the startup procedure to complete and the client has to wait a long time for the response. In our scenario this is unacceptable. In the first place I suggest to make an configuration option for the app life timeout with the possibility to disable the timeout entirely. In the case the process crashes, this is still not a solution. That's why I recommend to make another option in the configuration whether the process should be started as soon as the request arrives or immediately after the crash.

Thanks in advance

[guardrex]

See: aspnet/KestrelHttpServer#1085, which links to some info on this in aspnet/IISIntegration#161. Your other option is any service that will ping the site regularly to keep it alive.

... but late in the KestrelHttpServer thread, where I mention view precomilation, that's old news. That's a real thing now: https://github.com/aspnet/MvcPrecompilation and aspnet/Announcements#217

[pxdeveloper]

@guardrex Thank you for your answer.

In our case we have a web service (REST API) without views, so there is no view compilation at all. It's the startup process itself with dependency injection and stuff that needs about 4 seconds. Our service should be ready all the time. We have managed to keep the IIS worker process 'w3wp.exe' alive, but we have no control to keep our service running, as the 'w3wp.exe' (with the AspNetCoreModule running inside) kills the process after some time. To keep the service alive with pings from another service is not an elegant solution. It would be only a temporary solution.

[guardrex]

They plan to endow Kestrel with the features it needs to work as a public-facing server (e.g., aspnet/KestrelHttpServer#1074 (comment) and comments made in the standups). I kind'a wish they had an open issue with a missing feature list so we could see how the work is progressing. Many of the needed bits have been added.

When Kestrel gets these missing features (especially the missing security features), you'll be able to run your service directly on Kestrel (no IIS) and this problem of keeping the app warm will go away. I asked [@]DamianEdwards if the features would be added to Kestrel by the end of 2017. He said "maybe." 😁

Would WebListener work for you? That would take IIS out of the picture, thus it might solve your cold app problem.

[pxdeveloper]

@guardrex Thank you again for the informations.

We will try out the WebListener.

[shirhatti]

I was wondering why the process specified by 'processPath' always got killed when there were no incoming requests for a long period of time. My first thoughts were that the app crashed, but then I monitored it for silent process exits using 'GFlags.exe' and realized that it was the 'w3wp.exe' who killed the process.

The Application Pool idle timeout is configurable in IIS. That should help solve part of your problem.

That's why I recommend to make another option in the configuration whether the process should be started as soon as the request arrives or immediately after the crash.

Auto-start is something on our backlog #29