Recently I was talking with a colleague about long running processes in IIS. This is considered a bad practice for a number of reasons. IIS is made to serve many different requests concurrently, often of short duration. If you have long running processes, you can dramatically impact yours, and potentially other applications performance.
For example, IIS will be configured sometimes to roll the app pool(s) on a regular basis. If you have long running processes, this can conflict with the attempt to roll an app pool. Unexpected results could occur, or you could block the rolling of the app pool. In my opinion, this behavior of IIS is due to fixing symptoms rather than root causes of problems.
The primary reason they roll the app pool is because a process may become abandoned, but not stopped. It is using resources, but cannot be connected or terminated. Another issue is memory leaks. So, rather than fixing software that fails in a graceful fashion, they simply reboot. Well, it is windows, right? That’s how we fix everything. Just reboot (roll the app pool).
When asked, “Where would you then run a long running process that you make available as a RESTful web service”, the answer was, run it as an NT Service using a pure Web Api executable. Or, use a third party web server software, and run your process there. My immediate thought was, if I have a memory leak in my code, will it not be presented in those other hosting environments as well? If I run it as a Windows service on the same machine, and it consumes too many resources, how is that any different? The server has the same resources if I run it as an IIS process or a Windows Service. Putting the app in its own App Domain under IIS is pretty much the same as running it in a separate Windows Service.
I’m not recommending you violate the recommendations for IIS. That is definitely not my area of expertise. However, I do find the arguments given to be equivalent to any other alternative host. You really need to write good software, regardless of your hosting environment. That’s my thoughts anyway.
Cheers,
Ben