最近我在WCF前端做了很多工作，特别是在IIS中托管（不是自托管）。
只是我，还是有人有微调超时值的问题。我首先要提到你需要立即微调的超时数量。
查看以下绑定端点值，这些值以某种方式与超时相关：
这些只是客户端端点配置值，我们还没有开始，现在为了让服务在IIS中运行，还需要设置服务器端绑定，这提供了与客户端。
一旦完成，配置IIS也是必不可少的，否则在长时间调用WCF服务期间，最终会导致主线程中止。
IIS需要禁用keep-alives，App Pool还附带了大量的超时值App Pool，这本身就是一个详细的主题。除此之外，还有另外7个超时值需要特别微调，否则期望您的复杂WCF调用失败。
对不起，但其他人闻到老鼠的味道吗？
我的理解是，由于信任问题，基本上（大多数）这些超时值存在。通过信任，我的意思是“我们不相信服务会在合理的时间内做他们应该做的事情”。 SOA可靠通信的每个方面都是预先不信任的，因此，我们似乎需要大量的捕获网络（超时值）来确保某种程度的可管理性。让我们面对它，如果我们信任系统及时给出响应，为什么需要设置超时值？
我对这一切的问题是坦率地回到前面，如果我在我的应用程序中拥有的5个系统通常是可信的并且通常会给出及时响应。我很沮丧，我仍然需要经历漫长的定义这些边界的过程，因为OOB，WCF / IIS托管失败。
我观察到WCF技术是虚伪的，在网络广播和营销演示期间，通常总是提到WCF允许更好地从实现中抽象，允许开发人员更容易编写和部署，并且“简单地”定义端点是能够专注于业务逻辑，而不是下划线架构。我在实践中发现没有什么能比真相更进一步。使用WCF，您需要深入了解服务的运行方式，并且需要手动微调，与ASMX服务不同，ASMX服务通常部署时没有太大的麻烦，只需要一些IIS微调，甚至很少。
所以我提出的问题是：只是我或你们中的任何人分享同样的挫折和观察吗？欢迎所有评论！
答案 0 :(得分：2)
从哪里开始？
您必须记住的是，WCF服务的架构独立于托管应用程序。您可以根据您的方案和需求在命令行应用程序，WinForms应用程序，Windows服务，IIS，Silverlight，Win32应用程序，MFC应用程序等中托管WCF服务。
因此，需要独立控制和配置WCF基础架构和托管应用程序基础架构。
在您的情况下，您已选择在IIS中托管WCF服务。对于广泛的场景来说，这是一个很好的选择，但在其他场景中则选择不当。为什么？因为 IIS专门针对非常有针对性的场景构建：接收和分派对短期工作进程的请求并将响应返回给调用者。
这个“短命”的陈述是故意的：IIS主要用作Web服务器。因此，默认配置为充当Web服务器。 Web服务器通常配置为尽快响应呼叫者。除非工作进程返回响应，否则Web服务器不知道页面请求生成的工作进程是“忙”还是“挂起”。在收到响应之前，Web服务器只能假定工作进程“忙”。如果工作进程在给定（可配置）时间段内没有响应，则Web服务器决定终止工作进程，因为它可能已挂起。
因此，在您的场景中，您使用IIS来托管具有特殊要求的非典型应用程序（即执行长时间运行操作的能力）。如果您，应用程序开发人员/管理员知道某些应用程序可能无法返回超过10分钟，那么您可以拨入托管特殊情况应用程序的工作进程的超时期限。这是一件好事。如果你没有得到这种能力，当你的代码中的错误或数据库层的速度减慢导致整个网络服务器瘫痪杀死该机器托管的每个网站时，你会尖叫，因为你的工作进程没有超时。
许多相同的逻辑适用于WCF配置设置：
您注意到的所有设置都允许您通过修改其配置设置来控制WCF服务的性能特征 - 无需更改代码行和/或部署新位（假设您通过配置文件配置服务而不是通过代码控制这些设置。
如果您似乎指出，您具有执行长时间运行任务的WCF服务，您可以选择不在IIS中托管它们并将它们托管在Windows服务应用程序中。在这种情况下，您的托管应用程序除了托管您的服务之外几乎不会做任何其他事情，而是适当地响应启动和关闭通知。那么如何控制服务处理具有非常大的有效负载的消息的能力？您如何控制同时创建的服务实例数？您如何控制WCF等待新服务实例打开和/或关闭的时间？
很高兴您有机会更改/部分/全部这些以及其他一些设置，并且非常容易地控制服务的性能，安全性，可靠性和行为。这可能会更糟糕 - 您可能完全无法控制您的服务或主机，并且不得不接受您所提供的任何性能特征。