Reusing application pool results in very long response times

Question

I read somewhere that recycle of the application pool should not be very noticeable to the end user when the overlap is on, but in my case it leads to at least 10 times longer responses than usual (depending on the load, the response time from the usual 100 ms to 5000 ms). In addition, this is not for a single request, but several of them immediately after the recycling of the pool (during testing, I used ~ 10 parallel connections).

So the questions are:

• In my opinion, I am not doing anything, it will take a lot of time when starting the application - in general, it is only an IoC container and routing initialization, even I would do something - is that what overlap should overlap, or not?
• Is the sql connection pool removed during pool reuse and can this be the cause of a long response time?
• What would be the best way to profile what took so long? There may also be ideas that it may take so much time on the part of IIS / .NET and how to avoid it.

Answer 1

• Overlapping only means that the old workflow will work while the new one is running. As soon as a new one starts, it starts to process all requests. "Started" does not mean that initialization is complete (which may be contained in Application_Start, any static constructors in your application, or any one-time, complex tasks such as creating a proxy). This means that new requests will have to wait until these processes are completed, although the "old" workflow may be available in a short time. In addition, if your application uses any kind of caching, your new caches will be "cold", that is, it will take some additional processing time until the caches are warmed up.

• Yes - your new application will have a new sql connection pool.

• In my experience, in a production environment, with well-tested code and an application that requires consistent, high performance, I choose to completely disable the application pool utility. Recycling an application pool is a “feature” introduced to combat the perception that IIS is unstable when in fact what was usually unstable was the applications that it hosted. In my opinion, this is a crutch that allows people to install less stable code. If this causes problems, disable it and make sure that your application does not have memory leaks, etc., which can lead to long-term instability of the application.