WCF / IIS 超时是否需要重写？

Question

最近我在 WCF 方面做了很多工作，特别是在 IIS 中托管（不是自托管）。

只是我，还是有人在微调超时值时遇到问题。我将首先提到您需要立即进行微调的大量超时。

查看以下以某种方式与超时相关的绑定端点值：

• closeTimeout="00:01:00"
• openTimeout="00:01:00"
• receiveTimeout="00:10:00"
• sendTimeout="00:01:00"
• maxBufferSize="999"
• maxBufferPoolSize="524288"
• maxReceivedMessageSize="999"
• readerQuotas maxDepth="32"
• readerQuotas maxStringContentLength="8192"
• readerQuotas maxArrayLength="16384"
• readerQuotas maxBytesPerRead="4096"
• readerQuotas maxNameTableCharCount="16384"

这些只是客户端端点配置值，我们还没有开始，现在要让服务在 IIS 中运行，还需要设置服务器端绑定，它提供与客户端。

完成后，配置 IIS 也很重要，否则在长时间调用 WCF 服务期间，您最终会导致主线程被中止。

IIS 需要禁用 keep-alives，App Pool 还带有大量超时值，App Pool，这本身就是一个详细的主题。除此之外，还有大约另外 7 个超时值需要特别微调，否则可能会导致复杂的 WCF 调用失败。

对不起，有没有人闻到老鼠的味道？

我的理解是，基本上（大部分）这些超时值是由于信任问题而存在的。所谓信任，我的意思是“我们不相信服务会在合理的时间内完成他们应该做的事情”。 SOA 可靠通信的每一个方面都是不可信的，因此，我们似乎需要大量的捕获网（超时值）来确保一定程度的可管理性。让我们面对现实吧，如果我们信任系统能够及时做出响应，为什么需要设置超时值？

坦率地说，我遇到的所有问题都是从头到尾，如果我在我的应用程序中拥有的 5 个系统通常是可信任的，并且通常会及时做出响应。我很沮丧，因为 OOB、WCF/IIS 托管失败，我仍然需要经历定义这些边界的漫长过程。

我观察到 WCF 技术是虚伪的，在网络广播和营销演示期间，通常总是提到 WCF 允许更好地抽象实现，允许开发人员更轻松地编写和部署，并且通过“简单”定义端点是能够专注于业务逻辑，而较少关注底层架构。我在实践中发现没有什么比事实更离谱的了。使用 WCF，您需要深入了解服务如何运行的细节，并且您需要手动进行大量微调，这与 ASMX 服务不同，在 ASMX 服务中，它们通常无需大惊小怪地部署，并且只需要一些 IIS 微调，甚至很少。

所以我提出的问题是：只有我还是你们中的任何人有同样的挫败感和观察？欢迎所有cmets！

Answer 1

从哪里开始？

您必须记住的是，WCF 服务的架构是独立于托管应用程序的。您可以根据您的场景和需求，在命令行应用程序、WinForms 应用程序、Windows 服务、IIS、Silverlight、Win32 应用程序、MFC 应用程序等中托管 WCF 服务。

因此，需要独立控制和配置 WCF 基础结构和托管应用基础结构。

在您的情况下，您选择在 IIS 中托管 WCF 服务。对于广泛的场景，这是一个不错的选择，但在其他场景中却是一个糟糕的选择。为什么？因为 IIS 是专门为一个非常有针对性的场景而构建的：接收和分派请求到短暂的工作进程并将响应返回给调用者。

那个“短命”的说法是经过深思熟虑的：IIS 主要用作 Web 服务器。因此，默认配置为充当 Web 服务器。 Web 服务器通常配置为尽可能快地响应调用者。 Web 服务器不知道由页面请求生成的工作进程是“忙”还是“挂起”，除非工作进程返回响应。在收到响应之前，Web 服务器只能假设工作进程“忙”。如果工作进程在给定的（可配置的）时间段内没有响应，则 Web 服务器会决定终止工作进程，因为它可能已挂起。

因此，在您的场景中，您使用 IIS 来托管具有特殊要求（即执行长时间运行操作的能力）的非典型应用。如果您（应用程序开发人员/管理员）知道某些应用程序可能在 10 分钟内不会返回，那么您可以为托管您的特殊情况应用程序的工作进程拨入超时期限。这是一件好事。如果你没有被赋予这种能力，当你的代码中的一个错误或你的数据库层中的一个减速导致整个 Web 服务器崩溃时，你会尖叫，因为你的工作进程没有超时。

同样的逻辑也适用于 WCF 配置设置：

您记下的所有设置都允许您通过修改 WCF 服务的配置设置来控制其性能特征 - 无需更改一行代码和/或部署新位（假设您通过配置文件而不是通过代码控制这些设置）。

如果，正如您所指出的，您有执行长时间运行任务的 WCF 服务，您可以选择不在 IIS 中托管它们，而是在 Windows 服务应用程序中托管它们。在这种情况下，您的托管应用程序只会托管您的服务并适当地响应启动和关闭通知。那么，您将如何控制您的服务处理具有非常大有效负载的消息的能力呢？您将如何控制同时创建的服务实例的数量？您将如何控制 WCF 等待新服务实例打开和/或关闭的时间？

很高兴您有机会更改任何/部分/所有这些以及许多其他设置，并如此轻松地控制服务的性能、安全性、可靠性和行为。情况可能会更糟——您可能完全无法控制您的服务或它们的主机，并且必须接受给定的任何性能特征。