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

Question

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

所以问题是：

1. 在我看来，我什么都不做，这将花费很长时间来启动应用程序 - 通常，这只是 IoC 容器和路由初始化，即使我也会做一些事情 - 这就是重叠应该注意的，或不？
2. sql 连接池是否在池回收过程中被破坏，这可能是响应时间长的原因吗？
3. 什么是分析耗时这么久的最佳方法？也可能有一些想法，从 IIS/.NET 方面可能需要这么长时间，以及如何避免这种情况。

Answer 1

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

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

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