asp.net-mvc - 应用程序池回收导致响应时间很长

Question

我在某处读过，当启用重叠时，应用程序池回收对最终用户来说不应该很明显，但在我的情况下，这会导致响应时间至少比通常长 10 倍(取决于负载、常规响应时间) 100 毫秒增长到 5000 毫秒)。此外，这不是针对单个请求，而是针对池回收后的多个请求(我在测试时使用了大约 10 个并发连接)。

所以问题是:

在我看来，我什么都不做，这会在应用程序启动时花费很长时间——一般来说，这只是 IoC 容器和路由初始化，即使我也会做一些事情——重叠应该注意什么？

在池回收期间 sql 连接池是否被破坏，这可能是响应时间长的原因吗？

描述需要这么长时间的内容的最佳方法是什么？也可能有一些想法，IIS/.NET 方面可能需要这么长时间，以及如何避免这种情况。

Answer 1

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

是的 - 您的新应用程序将有一个新的 sql 连接池。

根据我的经验，在具有经过良好测试的代码和需要一致、高性能的应用程序的生产环境中，我选择完全禁用应用程序池回收。应用程序池回收是一项“功能”，旨在消除 IIS 不稳定的看法，而实际上，通常真正不稳定的是它托管的应用程序。在我看来，它是一个拐杖，它允许人们部署不太稳定的代码。如果它给您带来了问题，请将其关闭并确保您的应用程序没有任何可能导致应用程序长期不稳定的内存泄漏等。