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”

这些只是客户端端点配置值，我们甚至还没有开始，现在为了让服务在II中运行S，还需要设置服务器端绑定，它提供与客户端相同级别的复杂性。

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

IIS需要保持禁用状态，应用程序池还带有大量的超时值App Pool，这是一个详细的主题。除此之外，还有另外7个超时值需要特别微调，否则会期望复杂的WCF调用失败。

对不起，但其他人有没有闻到老鼠？

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

我所有这一切的问题是，坦率地说，它回到前面，如果我在我的应用程序中有5个系统通常是可信的并且通常会给出及时的响应。我很沮丧，我仍然需要经历冗长的定义这些边界的过程，因为OOB，WCF/IIS托管失败。

我发现WCF技术是虚伪的，在网络演员和营销演示期间，通常总是会提到WCF允许从实现中更好地抽象，允许开发人员更容易地编写和部署，并通过“简单”定义端点能够专注于业务逻辑，而不是强调架构。在实践中我发现没有什么比事实更能说明问题。有了WCF，您需要深入了解服务运行的细节，而且您需要手动进行微调，与ASMX服务中通常部署时没有太多争论的情况不同，而且只需要一些IIS微调，甚至很少。

所以我提出的问题是：它只是我还是你们中的任何一个人都有同样的挫折和观察？欢迎所有评论！

Answer 1

从哪里开始？

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

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

就你而言，你已经选择在IIS中托管你的WCF服务。对于广泛的场景来说，这是一个很好的选择，但在其他场合选择不佳。为什么？因为IIS专门为非常有针对性的场景而构建：接收和发送对短期工作进程的请求并将响应返回给调用者。

“短命”陈述是故意的：IIS主要用作Web服务器。因此默认配置为充当Web服务器。 Web服务器通常配置为尽可能快地响应呼叫者。除非工作进程返回响应，否则Web服务器不知道页面请求产生的工作进程是“繁忙”还是“挂起”。在收到响应之前，Web服务器只能假定工作进程处于“繁忙”状态。如果工作进程在给定的（可配置的）时间段内没有响应，那么Web服务器决定终止工作进程，因为它可能是挂起的。

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

大部分的逻辑同样适用于WCF配置设置：

所有设置你注意让你通过修改其配置设置来控制你的WCF服务的性能特性 - 无需更改任何代码和/或部署新的位（假设你通过配置文件来配置你的服务，而不是通过代码来控制这些设置）。

如果您似乎指出，您有WCF服务执行长时间运行的任务，您可以选择不将它们托管在IIS中，而是将它们托管在Windows服务应用程序中。在这种情况下，您的托管应用程序除了托管您的服务以外，并没有做任何其他事情，而是恰当地响应启动和关闭通知。那么如何控制你的服务处理消息的能力非常大？你将如何控制同时创建的服务实例的数量？你将如何控制WCF等待新服务实例打开和/或关闭的时间？

很高兴您有机会改变这些和其他一些设置中的一些/某些/全部设置，并非常容易地控制服务的性能，安全性，可靠性和行为。这可能会更糟糕 - 您可能完全无法控制您的服务或其主机，并且必须满足您提供的任何性能特征。