代码之家 › 专栏 › 技术社区 › Matt

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

iis wcf .net

Matt · 技术社区 · 6 年前

最近我在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 maxarrayleng=“16384”
readerQuotas maxBytesPerRead=“4096”
readerquotases maxNameTableCharCount=“16384”

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

完成后,还必须配置IIS,否则在长时间调用WCF服务时,主线程将被中止。

IIS需要保持alives被禁用,应用程序池还附带了大量的超时值,应用程序池,这本身就是一个详细的主题。除此之外,还需要对另外7个超时值进行专门的微调,否则复杂的WCF调用将失败。

对不起,还有人闻到老鼠味吗?

我的理解是,这些超时值的本质上是由于信任问题而存在的。我所说的信任,是指“我们不相信这些服务在合理的时间内做了他们应该做的事情”。SOA可靠通信的每一个方面都是不可信的,因此,我们似乎需要大量的捕获网(超时值)来确保某种程度的可管理性。让我们面对现实吧,如果我们信任系统及时给出响应,为什么需要设置超时值?

我所面临的问题是,坦率地说,如果我的应用程序中的5个系统通常都是可信的,并且通常会给出及时的响应,那会怎么样呢。我很沮丧,因为OOB、WCF/IIS托管失败,我仍然需要经历定义这些边界的漫长过程。

我注意到WCF技术是虚伪的,在web广播和营销演示过程中,人们经常提到WCF允许更好地从实现中抽象出来,允许开发人员更容易地编写和部署,并且通过“简单地”定义端点能够集中精力于业务逻辑,而不是强调建筑。我在实践中发现,没有什么比事实更离谱了。使用WCF,您需要深入了解服务操作的详细信息,并且需要手动进行大量微调,这与在ASMX服务中通常不需要太多麻烦就部署的服务不同,而且只需要一些IIS微调,甚至很少。

所以我提出的问题是:是只有我,还是你们中的任何人都有同样的挫折感和观察?欢迎所有评论!

1 回复 | 直到 13 年前

Rich Turner 14 年前

从哪里开始?

您必须记住,WCF服务的架构独立于宿主应用程序。您可以根据您的方案和需要,在命令行应用程序、WinForms应用程序、Windows服务、IIS、Silverlight、Win32应用程序、MFC应用程序等中托管WCF服务。

因此,WCF基础设施和托管应用程序基础设施需要独立控制和配置。

在您的情况下,您选择在IIS中托管WCF服务。对于很多场景来说,这是一个不错的选择,但在其他场景中则是一个糟糕的选择。为什么?因为 IIS是专门为一个非常有针对性的场景而构建的:接收和分派对短期工作进程的请求,并将响应返回给调用者。

这个“短命”语句是经过深思熟虑的:IIS主要用作web服务器。因此,默认情况下配置为充当web服务器。Web服务器通常配置为尽快响应调用者。除非工作进程返回响应,否则web服务器不知道由页面请求生成的工作进程是“忙”还是“挂起”。在收到响应之前,web服务器只能假设工作进程“正忙”。如果工作进程在给定的(可配置的)时间段内没有响应,那么web服务器将决定终止该工作进程,因为它可能已挂起。

因此,在您的场景中,您使用IIS托管一个具有特殊要求(即执行长时间运行操作的能力)的非典型应用程序。如果应用程序开发人员/管理员知道某些应用程序返回的时间可能不超过10分钟,则可以拨入承载特殊情况应用程序的工作进程的超时时间。这是件好事。如果你没有被赋予这种能力,当你的代码中的一个bug或者数据库层的一个慢下来导致整个web服务器瘫痪时,你会尖叫,因为你的工作进程都没有超时,所以杀死了由该机器托管的每个web站点。

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

您注意到的所有设置都允许您通过修改WCF服务的配置设置来控制其性能特征,而无需更改代码行和/或部署新的位(假设您通过配置文件配置服务,而不是通过代码控制这些设置)。

如果如您所示,您拥有执行长时间运行任务的WCF服务,则可以选择不在IIS中承载这些服务,而在Windows服务应用程序中承载它们。在这种情况下,你的托管应用程序除了托管你的服务外几乎没有其他作用,而是对启动和关闭通知做出适当的响应。那么,您如何控制您的服务处理具有非常大有效负载的消息的能力呢?如何控制要同时创建的服务实例的数量?如何控制WCF等待新服务实例打开和/或关闭的时间?

很高兴你有机会改变这些设置和一些其他设置,并很容易地控制服务的性能、安全性、可靠性和行为。更糟糕的是,您可能完全无法控制您的服务或它们的主机,必须使用您所提供的任何性能特征。