WCF 调用的 IIS 请求限制回收

Posted 2023-02-14

【中文标题】WCF 调用的 IIS 请求限制回收

【英文标题】：IIS Request Limit Recycling for WCF calls

【发布时间】：2017-09-22 20:42:49

【问题描述】：

我们有一个专用于不经常调用的 WCF 服务的应用程序池（可能每天 15-20 次）。但是，这些调用可能需要几分钟，而前几天，当 IIS 回收应用程序池时，由于关闭超时已用完，调用仍在处理中，我们被烧毁了。

我们正在考虑使用请求限制回收，但我的问题是：当应用程序池“在 x 请求之后”回收时，是在 x 之后请求完成了吗？还是它会启动请求，启动重叠进程来处理新请求，然后使第 x 个请求受到当前烧毁我们的相同关闭超时？

类似的问题：How to detect if the current application pool is winding up in IIS7.5 and Asp.Net 3.5+

【参考方案1】：

检查您在应用程序池中的关闭时间限制设置。

无论您如何进行回收，都会检查此设置以确定请求在被强制关闭之前允许进行多长时间。

当应用程序池被回收时，IIS 会首先尝试从应用程序池中排出正在运行的请求，然后是，与此同时，一个新的应用程序池已经启动并接受新请求。通过将设置设置得足够高以适应您长时间运行的请求，您将允许 IIS 安全地耗尽旧的应用程序池。

【讨论】：

你说的不是相当正确...回收与应用程序池重叠，因此在旧的终止之前启动新的。但是，是的，这就是燃烧我们的环境。我很犹豫是否将其延长几分钟，但我们可能不得不......不过，它必须与 WCF 请求超时相匹配才能有意义。

对...好的，是的，您对应用程序池的时间是正确的，我已经进行了编辑。尽管您自己承认，答案仍然是正确的，因此希望您接受它。顺便说一句，您的请求超时应该已经很长，或者您已经遇到终止请求。你是对的，关闭时间限制应该等于或小于执行超时。

我没有忘记您的答案，只是将问题留待其他答案。我还在寻找延长关机超时的缺点......为了匹配 WCF 服务设置，我需要将关机超时设置为 20 分钟（我们最坏的情况 + 填充） - 对此并不疯狂。抱歉，我并不是要听起来很迂腐——这种差异是我问题背后的希望。新实例立即启动，当前实例可以允许当前请求完成而不会产生影响。但我相信你说它没有，这几乎是我所期望的。

理想情况下，我希望关闭超时仅适用于应用程序关闭事件，这些事件在进程内请求完成之前不会触发——毕竟这些都有自己的超时。我得到了反对为什么不应该这样做的论据，但后来我又绕了一圈——如果超时时间很短是有原因的，那么把它加起来是个坏主意。

嗨詹姆斯 - 不用担心，我明白你在说什么。是的，我是说如果当前请求超过关闭时间限制，当前实例将不允许完成当前请求。我不同意您对将关闭时间限制设置为高的担忧。您已经有一个长时间运行的请求 - 您必须在执行时间限制和应用程序池关闭时间限制内完成该长时间请求。 ***.com/a/7073044/1165140 的另一点是它会等待到限制，如果请求提前完成，那么它将提前终止应用程序池。

【参考方案2】：

我建议您执行以下操作。

1- 在您的 WCF 服务下创建一个 bool Ping() return true; 方法。

2- 创建一个负责轮询 Ping() 方法的 IIS Web 应用程序。这是我发现让我的 WCF 服务保持活跃的唯一方法。

3- 还必须从另一个后台 IIS 进程（Web 应用程序）调用 WCF 长时间运行的操作，该进程必须从消息队列中读取并调用 WCF 操作。因此，您需要将 WCF 长时间运行的操作调用请求记录在队列中。这样，如果托管您的 WCF 服务的应用程序池关闭，您将有可能重试调用。

【讨论】：

我不清楚这如何防止关机超时... IIS 有一个对服务的内置 ping，配置设置为在考虑应用程序死机之前等待的频率和等待时间.无论哪种方式，服务都没有死，它很忙...... ping 不会告诉我每个调用实例是否已完成处理。这听起来像是一个相当复杂的设计架构，我没有看到它给我带来了什么？ （该调用是从 Windows 服务发出的，当然可以重试该操作，但一般来说，完成当前调用比重试更可取）

我了解您的信息。在我看来，无论您对 WCF 应用程序池设置进行什么更改，w3wp.exe 进程都会在不活动时间后关闭。如果你真的想让它保持活动状态并提高第一次调用（关闭后）的性能，唯一的方法是每 x 分钟轮询一次服务。如果排队和重试不是一个好的解决方案，那么我只能建议您努力提高 wcf 操作的性能，或者尽可能将其隔离为多个小操作。