通常情况下，我在IIS中托管我的WCF服务，但我的同事告诉我，当在本地服务中托管时，服务运行得更好（性能明智）。
这是真的吗？每种方法的优缺点是什么？
答案 0 :(得分：1)
如果不知道您的服务是如何设计的，它们消耗了多少CPU /内存，它们支持多少并发客户端，访问它们的方式等等，那么很难对哪种方法更好地做出一般说法/快点。所以我将分享我之前的经历。
在针对两种WCF部署方法进行一些基本性能测试之后，我们最初在本地Windows服务中托管了我们的WCF服务。在Win Svcs中托管它们的速度略快（不明显）。 .NET 4.0 / REST / wsHTTPBinding /总计3,000浓。调用/加载平衡服务器场/内存密集型/默认WCF设置（最初没有调整它们）。
然后我们注意到我们的WCF服务器上的内存在启动服务几天后最大化，当它发生时，我们的服务偶尔会产生奇怪的异常。我们打开服务器上的perf计数器。当我们了解到Win Svc中托管的WCF服务的性能分析并没有给我们提供很多见解时，因为许多性能计数器根本没有返回任何信息，这已得到Microsoft的确认技术支持团队。我们还使用ANTS来查找内存泄漏但在我们的代码中没有发现任何重大问题。然后，我们在Microsoft顾问的帮助下，专心地调整了WCF设置（例如maxbufferpoolsize）。最终我们得出的结论是，GC并不经常发生以释放分配的内存。我们甚至尝试从工作站模式切换到server mode GC，这实际上最终使问题恶化。
作为最后的手段，我们切换到了IIS。服务的表现并没有好转，这是完全可以预期的。但是，一些特定于IIS的性能计数器证实了我们对GC不经常发生的怀疑。然后，我们在IIS中发现了这个非常棒的setting，它允许我们specify when and how often to recycle an app pool。是的，我们可以开发一个简单的自定义解决方案来重新启动我们的WCF服务，但为什么要重新发明轮子，我们想。此外，当您在IIS中回收应用程序池时，IIS doesn't kill it abruptly。相反，它创建一个新的处理后续请求，而旧的请求保持活动一段可配置的时间来完成处理所有未完成的请求。这种内置功能使我们能够保持正常运行时间SLA。
根据我的经验，我建议你将它们保存在IIS中，除非你真的真的需要从服务器中挤出最后一点果汁。