【发布时间】：2011-01-09 01:44:56
【问题描述】：
为了快速构建搜索网站，我计划将工作分配给两个团队：一个负责构建搜索引擎，另一个负责构建 Web UI（移动/桌面）。我的计划是将搜索引擎构建为一组基于 .NET 3.5 的 REST 服务。用户界面可以使用其他技术构建。
问题：REST 接口是否可能成为性能瓶颈？如何最好地避免这种情况？
【问题讨论】：
标签： asp.net wcf search .net-3.5 rest
【发布时间】：2011-01-09 01:44:56
【问题描述】：
REST 在这种情况下不太可能成为瓶颈。从您的帖子中不清楚您是直接从客户端上的 HTML UI 进行 REST 调用，还是在后端进行服务器到服务器的 REST 调用。所以我将在下面介绍这两种情况。
如果您的 REST 调用是在您的客户端 UI 和您的服务器之间进行的，那么使用 REST 或其他 HTTP 远程处理方法的影响相对较小——在后端执行搜索然后将结果发送回所需的时间对客户端的影响应该使 REST 调用本身的影响相形见绌。如果您想提高性能，请专注于客户端网络技巧（例如 HTTP 压缩、适当的缓存标头等）并优化您的搜索引擎本身。
如果您的架构是一层服务器（托管您的 Web UI）调用另一层（您的搜索引擎），那么通过 REST 在这些层之间进行调用也不应该给您的整体延迟增加太多。这是因为（与上面相同）运行搜索并将结果发送回客户端通常至少需要几百毫秒，而后端 REST 调用的开销（如果处理得当）通常为 50 毫秒或更短.
也就是说，很容易弄乱服务器到服务器 HTTP 调用的客户端。例如，许多 HTTP 客户端库（包括 .NET 的）默认情况下会限制并发客户端连接的数量，如果您正在构建一个实际的客户端应用程序，这是有道理的，但如果从实际上是服务器同时为数百个用户提供服务。其他潜在问题包括身份验证问题、代理问题、DNS 等。因此，请小心谨慎地构建和配置 REST 客户端代码，并确保对数百个并发用户进行负载测试！
【讨论】：
-
是的，该体系结构将涉及调用后端 REST 的服务器端表示方法。感谢您提供有关扩展的提示 - 这当然很重要，因为该网站需要每周提供 200 万页的展示次数。
-
我会走得更远，说为什么还要麻烦使用 REST 来进行服务器到服务器的通信。您已经在使用 WCF，您可以控制交互的双方。为什么不直接定义 WCF ServiceContract？ REST 非常适合减少客户端和服务器之间的耦合，而 HTTP 非常适合网络中的客户端，但是如果您的服务器彼此相邻，为什么要为此付出代价？
-
WCF 是我们通常会使用的，但在这种情况下，我们可能必须是异构的 - 不能自始至终假设 MS
-
在测试中，我们发现 WCF over HTTP 和二进制压缩是两个 Windows 服务器（“web”和“app”）之间通信的最佳折衷方案。它易于配置且相对较快。 TCP 可能更快，但更难配置。在单台机器上命名管道会更快，所以我们最终可能会在同一台机器上组合 'web' 和 'app' 。我们的数据存储是基于 Linux 的，我们使用 REST 风格的调用与它进行通信。到目前为止，完全没有性能问题。
没有。 REST 不是（通常也不会是）瓶颈。没有花哨的 HTML 页面的 REST 是 HTTP。它比普通网页更便宜、更快捷。
【讨论】：
我认为它不应该影响你的表现，但要正确使用 REST 服务。Net 有完全支持 REST 的 ASP.Net MVC。
记得通读此链接http://www.ytechie.com/2008/10/aspnet-mvc-what-about-seo.html
【讨论】：
-
MVC 支持一些以 html 为中心的开发，并且为 html 或 json 驱动的应用程序提供足够的 HTTP。与任何其他允许您访问 http 标头和流的框架相比，它不再完全支持 ReST。