多贵啊？ - 托管WCF服务？

Question

当“费用”这个话题出现时，我和同事正在讨论WFC服务。

问题是：

鉴于IIS托管的WCF服务和Windows服务托管的WCF服务完全相同，如果它们都接受相同的负载，哪个服务在内存和CPU周期方面会更“昂贵”？

我们并不关心初始启动编码，安装或配置（IIS似乎旨在提供更简单的体验），而只是运行服务的简单成本。

Answer 1

我无法提供具体的数字，但如果这是一个大问题，你肯定应该进行性能测试。对于典型的基于HTTP的WCF服务，所有请求最初将由Windows内的http.sys处理，然后分派到适当的进程。无论您的服务是在IIS中还是在独立服务中托管都与您使用的WCF特定配置设置无关，就每次调用，每会话或单一配置以及请求大小限制和请求限制而言。 / p>

我会专注于可用性，而不是严格意义上的性能数据，因为它们应该几乎相同。

底线：在必要时使用更方便的性能测试。

Answer 2

基于IIS或Windows服务的WCF托管之间的一个非常重要的性能考虑因素是绑定类型。 IIS仅支持通过HTTP运行的WCF绑定，例如wsHttpBinding。 basicHttpBinding等等。

通常已知非Http绑定具有更好的性能，例如netTcpBinding（要求服务和客户端都是基于WCF的我认为）或netNamedPipeBinding（最快，但服务/客户端）必须在同一台机器上）。这些当然有其自身的局限性，尤其是灵活性。

以下是一个很好的概述：http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx

这里有一个非常类似的讨论：WCF Binding Performance

Answer 3

我知道这完全没有回答你的问题，但我想分享一下我的经验。

我有一个Windows控制台应用程序，在计划时调用IIS中托管的WCF服务。在这种架构中，IIS实际上是完全没必要的，只是整个解决方案的一个附加组件。出于营销原因，它确实包含在解决方案中，以加强产品，而不是出于技术原因。

这些是我面临的主要问题，以及为什么我会出于技术原因避免使用IIS，这适用于我的经验。请注意：我不是说在IIS中托管WCF服务是个坏主意。我只是从我目前正在处理的产品中提出我的想法。

1. 在循环中使用IIS意味着在整个解决方案中使用另一个系统。这反过来又增加了部署的复杂性。一些客户有IIS6其他客户运行7.虽然这些差异表面上可能看起来很小。毫无疑问，它们仍然不同，这意味着如果您将产品部署到不同的客户端，则会增加更多的环境差异。不要低估这些差异。我甚至有客户试图在SharePoint网站集中运行我的WCF服务（呃！）这一点比你想象的要多得多。
2. IIS也有AppPool注意事项，可能需要根据产品的复杂程度进行配置。 AppPool需要运行身份，再次为您的整体解决方案增加复杂性。
3. 我遇到过一些问题，单线程服务有时会“有趣” - 线程中止消息。虽然我仍在努力找出确切的原因，但在我的脑海里，我真诚地希望这与IIS无关。关键是如果我从整体解决方案中删除IIS，我就不会考虑这个问题。
4. 我听说过IIS是一个更强大的WCF服务托管环境与自托管的托管环境。我不完全确定这有任何重量。如果您知道自己在做什么，那么您的自托管服务应该没有理由不可靠。但我想，实现IIS中的一些自动功能需要更多的工作，例如WP回收。
5. 我对循环中的IIS并不总是不满意，但是当我将产品交给部署时，它很痛苦，没有强大技术背景的顾问必须设置IIS应用程序。通常情况可能会出错，并且涉及具有更多技术经验的人介入并解决。如果您是自托管，则可以更轻松地打包您的应用以进行部署。
6. 很抱歉重申，但如果你选择IIS，你的解决方案中将有2个应用程序，而不是1个，即使组织的业务部门只将应用程序视为一个业务部门，基本上不了解完整的复杂性您正在实施的解决方案。例如：为什么我们有2个配置文件？为什么我们要两次配置邮件？为什么我们必须将DLL部署到2个位置。这些问题经常被问到。
7. 最后我想我会提到，如果你是远程工作或通过VPN工作部署到客户端，情况会变得更糟，有时候顾问可以访问你没有的敏感区域。作为开发人员，尝试从整体解决方案中消除尽可能多的额外行李。让我们也提一下，系统管理员有时会发布一个方便的IIS重置，如果你的应用程序与其他人一起托管，他们将重置你的服务。

根据我的经验减少系统=减少可能出错。但您需要决定是否具备实施可靠的自托管服务的技能。这反过来又与开发，部署和维护的成本直接相关。