Remoting性能优势

性能

 如果性能对您的设计确实至关重要，那么通过 TCP
使用二进制消息格式的 Remoting 确实提供了一些显著的性能优势。

　　这里是从这篇文章中总结出的一些性能统计：

　　图例：ASMX – Web 服务，其他都是 Remoting 解决方案，WS 表示集成远程组件的 Windows
服务。

　　如上所示，对于 WS_TCP_Binary，其中的对象被配置为使用 TCP 通道和 Binary 格式化程序，而主机是 Windows
服务，其性能要优于其他的分布式技术。这是因为该方法通过原始 TCP 套接字传输二进制数据（比 HTTP
的效率高），且数据不需要编码/解码，因而降低了系统开销。可以看到，WS_TCP_Binary 和最慢的方法之间存在约 60%
的性能差距。

　　虽然 IIS_HTTP_Binary 与 WS_HTTP_Binary 产生的二进制负载相同，但其速度较慢，原因是从 IIS
(Inetinfo.exe) 到 Aspnet_wp.exe 之间有额外的进程跃点。IIS_HTTP_SOAP 与 WS_HTTP_SOAP
的性能差别也是由此造成的。

　　WS_HTTP_Binary 和 WS_TCP_SOAP 的性能几乎相同。尽管前者有 HTTP
分析方面的额外系统开销，后者有 SOAP 分析方面的额外系统开销，但在本例中 HTTP 分析的系统开销与 SOAP
分析的系统开销几乎相同。
ASP.NET Web 服务的性能优于 IIS_HTTP_SOAP 和 WS_HTTP_SOAP，因为 ASP.NET XML
序列化比 .NET Remoting SOAP 序列化的效率高。从上述内容可以看出，ASP.NET Web 服务与 IIS_HTTP_Binary
的性能几乎相同。”

　　如果原始速度确实非常重要，那么这“60% 性能差距”就很有意义了。其缺点是要将服务器集成在
Windows 服务中，以便使用 TCP 协议（请参阅前面的远程集成一节）。它有效地权衡了性能的安全性，而且是一种“最好不要用于 Internet
或不安全的 Intranet”的方法。

　　小结

　　ASP.NET Web 服务基于 XML，用于要求使用 HTTP（假定它们集成在
IIS）的实际应用中，能够提供简单的编程模式和强大的跨平台支持，它通过使用 SoapExtensions 提供了一定程度的扩展性，例如加密数据流。
Remoting 的编程模式更为复杂，但就协议和消息格式而言，它在类型保真、状态管理和扩展性方面具有明显的优势。

　　Remoting 不能用于非
.NET 客户端，因此无法实现 Internet 客户端与远程主机的直接连接。当在 IIS 之外集成时，Remoting 不能提供安全性模型。当集成在 IIS
时，Remoting 可以提供与 ASP.NET 相同的安全性功能，包括使用 SSL
等安全协议。如果不需要考虑与其他平台的互操作性，而且客户端和服务器的配置完全在您的控制之下，则可以考虑使用 .NET Remoting。使用 Remoting
时，使用了 HTTP 通道的 IIS 集成要优于非 IIS 集成，这样，可以得益于相关的安全性和伸缩性基础结构。当然，这意味着您必须能够在解决方案中与 IIS
进行互操作。如果这无法实现，那么使用 Remoting“可能”就是件无法实现的艰巨任务了，这与要解决的问题的性质有关。由于 .NET Remoting 要求使用
.NET 客户端，因此有必要使用最快的可用格式化程序，这样一来，选择二进制而不选择 SOAP 将产生更好的性能