应用程序池回收导致非常长的响应时间

Question

我已经在某个地方读过，当启用重叠时，应用程序池回收不应该对最终用户非常明显，但在我的情况下，响应的响应时间至少比通常长10倍（取决于在负载时，从常规100ms的响应时间增长到5000ms）。这也不是针对单个请求，而是在池回收之后的几个请求（我在测试时使用了~10个并发连接）。

所以问题是：

1. 在我看来，我什么都不做，这需要很长时间才能启动应用程序 - 一般来说，这只是IoC容器和路由初始化，甚至我也会做一些事情 - 这就是重叠应该采取的措施关心与否？
2. 在池回收期间是否破坏了sql连接池，这可能是响应时间长的原因吗？
3. 描述花费这么长时间的最佳方法是什么？也可能有想法，IIS / .NET方面可能需要很长时间，以及如何避免这种想法。

Answer 1

1. 重叠仅意味着旧工作进程将在新工作进程启动时继续运行。一旦新的启动，它就开始处理所有请求。 “已启动”并不意味着初始化（可能包含在Application_Start中，应用程序中的任何静态构造函数，或任何一次，代理构建等有争议的任务）都已完成。这意味着新请求必须在这些进程完成时等待，即使“旧”工作进程可能仍然可以在短时间内使用。此外，如果您的应用程序使用任何类型的缓存，您的新缓存将“冷”，这意味着在缓存预热之前需要一些额外的处理时间。

2. 是的 - 您的新应用程序将具有新的SQL连接池。

3. 根据我的经验，在生产环境中，经过严格测试的代码和需要一致，高性能的应用程序，我选择完全禁用应用程序池回收。应用程序池回收是一种“功能”，用于抵制IIS不稳定的感觉，实际上通常真正不稳定的是它托管的应用程序。在我看来，这是一个允许人们部署不到稳定代码的拐杖。如果它导致您出现问题，请将其关闭，并确保您的应用程序没有任何内存泄漏等，这可能会导致长期应用程序不稳定。