从 MSDN Code Center 下载 BDADotnet.msi 示例代码（英文）。
目录
简介
ASP.NET Web 服务和 .NET Remoting 为分布式应用程序中的进程间通信提供了一整套设计选项。通常，ASP.NET Web 服务的互操作性最好，并完全支持 HTTP 上的 WSDL 和 SOAP；而 .NET Remoting 可实现公共语言运行库类型系统的高保真，并支持其他数据格式和通信通道。有关详细信息，请参阅 ASP.NET Web 服务还是 .NET Remoting：如何选择。
本文主要对这两项技术的相对性能进行比较。
ASP.NET Web 服务
ASP.NET 提供以 Microsoft® IIS 作为宿主的基础结构，支持 SOAP、XML 和 WSDL 等行业标准。尽管 .NET Remoting 也支持 IIS 宿主和 HTTP 上的 SOAP，但 ASP.NET 却可提供最高级别的 SOAP 互操作性，包括对 SOAP Section 5 和 Document/Literal 的支持。
ASP.NET 可以充分利用 IIS 具有的功能，如安全性和日志记录。IIS 宿主也很强大，因为它可以在 Aspnet_wp.exe 终止后重新生成它。此外，由于 ASP.NET Web 服务的服务器和客户端的配置都已简化，因此与使用 .NET Remoting 提供的服务相比，它的创建和使用更为容易。
有关详细信息，请参阅 .NET Framework Developer's Guide 中的 Building XML Web Services Using ASP.NET（英文）。
.NET Remoting
.NET Remoting 更具通用性和扩展性，允许在使用不同传输协议和序列化格式的对象间进行通信。它支持二进制、SOAP、自定义格式以及 TCP、HTTP 和自定义协议。支持多对象创建和生存期模式，包括 Singleton、SingleCall 和 Client-Activated。Remoting 需要一个主机进程，可以是 IIS、Microsoft® Windows 服务或用 .NET 编写的可执行文件。
在具有 ASP.NET 的 IIS 中宿主使用 SOAP 格式化程序的 .NET Remoting 对象时，该对象可以公开为 XML Web 服务。由于有效负载以 HTTP 上的 SOAP 进行编码，因此任何支持 SOAP 编码格式的客户端均可通过 Internet 访问该对象。使用 HTTP 协议的另一个优点是它通常可以畅通无阻地通过大多数防火墙。TCP 通道和二进制格式化程序可以部署在服务器和客户端均运行 .NET Framework 的 Intranet 环境中。此方法的性能最佳，因为在使用原始套接字通过网络传输数据时使用了效率高于 HTTP 的自定义协议。尽管此方法在封闭环境中可以提供出众的性能，但它不能部署于客户端未运行 .NET Framework 的跨平台方案。
IIS 主机使用安全套接字层 (SSL) 为网络级保护提供安全通信，您也可以利用 IIS 和 ASP.NET 身份验证和授权。TCP 通道以及不通过 IIS 宿主的 HTTP 通道不支持安全套接字传输，因此其数据以明文形式传输。如果使用的是 TCP 通道或由非 IIS 进程宿主的 HTTP 通道，则您需要负责实现其安全性。
有关更多详细信息，请参阅 .NET Framework Developer's Guide 中的 .NET Remoting Overview（英文）。
测试方案
分布式应用程序中进程间通信的性能取决于以下因素：
用于跨远程边界的应用程序间传输信息的通道（包括 TCP 和 HTTP）占用的系统开销量。TCP 套接字比 HTTP 更为有效。
另一个因素是序列化。序列化流可以通过 XML、SOAP 或压缩二进制表示法进行编码。ASP.NET Web 服务使用 XMLSerializer 类将对象序列化为 XML 流，XML 流的速度非常快，但由于存在 XML 分析，因而需要一定的系统开销。Remoting 分别使用 BinaryFormatter 和 SOAPFormatter 将对象序列化为二进制格式和 SOAP 格式。由于这些格式化程序使用反射，因而对于引用对象很快，但对于必须经过装箱或取消装箱来通过反射 API 传递的值类型则较慢。此外，SOAPFormatter 还需要额外的系统开销以生成编码的 SOAP 消息。
本比较中使用的测试基于访问客户和订单数据的普通业务方案。为使测试尽可能符合实际，数据库中包含 100,000 多行客户帐户。数据位于 Microsoft® SQL Server™ 2000 数据库中，并使用 SQL Server .NET 数据提供程序连接到 SQL Server。
性能比较中使用了以下方法：
GetOrderStatus
GetOrderStatus 方法接受 OrderId 并返回表示订单状态的整数。
GetCustomers
GetCustomers 方法接受 CustomerId 和参数以指定想要读取的客户行数目，并读取 CustomerId 大于传递给 Web 服务方法的 CustomerId 的前 n 行。
测试过程中，我们通过具有不同页面大小（20 和 50）逐页提取小客户行集合。
测试工具和策略
测试中，ASPX Web 页调用包含测试代码的远程对象。尽管直接测试该技术（而不是通过在 Web 服务器后端测试）可以得到更好的绝对性能，但是在无状态环境中测试对于普通应用程序方案来说更符合实际。另外，有很多测试工具可以通过提供多线程测试和可靠的性能统计对 Web 页进行适当的强度测试。
在本测试中，我们使用了 Microsoft 应用程序中心测试 (ACT)。它可以对 Web 服务器进行强度测试，分析 Web 应用程序（包括 ASPX 页及其使用的组件）的性能和可伸缩性问题。有关如何创建和运行测试的详细信息，请参阅 ACT 文档。通过打开到服务器的多个连接并迅速发送 HTTP 请求，应用程序中心测试可以模拟一大组用户。它还允许我们建立实际的测试方案，我们可以在方案中使用一组随机参数值调用同一个方法。此功能很重要，因为用户不可能会使用相同的参数值反复调用同一个方法。另一个有用的功能是，应用程序中心测试可以记录测试结果，从而提供有关 Web 应用程序性能的最重要的信息。
如前所述，远程对象有两种激活方法 - 服务器激活和客户端激活。服务器直接控制服务器激活对象的生存期。服务器激活对象有两种激活模式 - Singleton 和 SingleCall。Singleton 类型不能同时运行一个以上的实例。所有客户端请求由一个实例提供服务，因此，使用该激活模式可以维护客户端之间的状态。另一方面，对于 SingleCall 类型而言，每个客户端请求由一个不同的实例来服务。客户端激活对象在服务器上创建，但这些对象的生存期却由调用应用程序域控制。使用此模式可以维护来自同一客户端的请求间的状态。ASP.NET 仅支持 SingleCall（即每个请求由一个新实例提供服务），如果服务是有状态的，则必须使用 cookie 和 SessionState 或自定义 SOAP 标头对其进行管理。在已经执行的所有用于比较各种远程选项的测试中，使用了 SingleCall 模式进行合理比较。
尽管 ASP.NET Web 服务支持 SOAP、HTTP-GET 和 HTTP-POST 选项，但为了保持一致性，测试中仅使用了 SOAP 选项。
HTTP/1.1 建议任何单个客户端与单个服务器之间至多建立两个连接。因此，当使用 HTTP 协议进行通信（如使用 HTTP 通道和 ASP.NET）时，在默认情况下，该协议在任何给定时间只打开两个到给定服务器的连接；而 TCP 通道可根据向服务器发出请求的线程数目，打开多个连接。为了模拟多个向远程对象发送同步请求的客户端，我们使用客户端配置文件将每个客户端与服务器的连接数目由默认值 2 改为 100：
使用 HTTP 通道进行远程通信时 - 使用客户端 .config 文件中的 clientConnectionLimit 属性：
<system.runtime.remoting> <application> ... <channels> <channel ref="http" clientConnectionLimit="100"> <clientProviders> <formatter ref="soap" /> </clientProviders> </channel> </channels> </application> </system.runtime.remoting>
对于 ASP.NET Web 服务，使用客户端 .config 文件中 <system.net> 中的 maxConnection 属性：
<system.net> <connectionManagement> <add address="*" maxconnection="100" /> </connectionManagement> </system.net>
由于允许与“localhost”（即客户端和服务器在同一计算机上）建立无限多个 HTTP 连接，因此不需要更改配置文件。
计算机配置
下表提供了用于执行测试的测试台配置的简单摘要。
表 1：客户端计算机配置
| 客户端数量 | 计算机/CPU | CPU 数量 | 内存 | 硬盘 | 软件 |
|---|---|---|---|---|---|
| 1 | Compaq Proliant 1130 MHz | 2 | 1GB | 16.9 GB |
|
表 2：Web 服务器配置
| 服务器数量 | 计算机/CPU | CPU 数量 | 内存 | 硬盘 | 软件 |
|---|---|---|---|---|---|
| 3 | Compaq Proliant 1000 MHz | 2 | 1 GB | 16.9 GB |
|
表 3：应用程序服务器配置
| 服务器数量 | 计算机/CPU | CPU 数量 | 内存 | 硬盘 | 软件 |
|---|---|---|---|---|---|
| 1 | Compaq Proliant 1126 MHz | 2 | 1 GB | 16.9 GB |
|
表 4：数据库服务器配置
| 服务器数量 | 计算机/CPU | CPU 数量 | 内存 | 硬盘 | 软件 |
|---|---|---|---|---|---|
| 1 | Compaq Proliant 700 MHz | 4 | 4 GB | 18 GB |
|
性能测试结果
吞吐量和滞后时间是关键的性能指标。对于给定数量的返回数据，吞吐量是指单位时间（通常是 1 秒）内处理的客户端请求数量。因为从可用性角度来看，吞吐量在某一响应时间达到峰值是不能接受的，因此我们跟踪了滞后时间，利用由应用程序中心测试为每个运行的测试生成的报告，将其作为响应时间进行测定。
跨计算机方案
在跨计算机方案中，远程客户端和远程对象位于不同的计算机中。ACT 客户端向 ASPX Web 页发送请求，该页随后调用远程对象中的方法。
图 1：跨计算机方案
如图 1 所示，测试是在 Web 服务器后端执行的，并存在数据库访问以及到外部计算机的网络跃点，从而增加了额外的系统开销。因此，生成的吞吐量和滞后时间性能值仅作为比较这两项技术的基础，它们不代表绝对性能。使用 ASP.NET Web 服务和 .NET Remoting 构建的分布式系统的精确吞吐量和滞后时间取决于所使用的体系结构。
GetOrderStatus
当从数据库中获得单个值后，我们将对各种技术的表现进行比较。
图 2：GetOrderStatus：吞吐量和滞后时间
注意：
- ASMX：ASP.NET Web 服务
- 所有其他选项表示不同的 .NET Remoting 配置。
- 在所有其他选项中，名称隐含了主机、使用的传输协议和格式，即 Host_TransaportProtocol_Format。
- “WS”即 Windows Service（Windows 服务）的缩写，它托管了远程类型。
- IIS_HTTP_Binary/SOAP 托管于带有 ASP.NET 的 IIS 中。
如图 2 所示（该对象配置为使用 TCP 通道和二进制格式化程序，主机是 Windows 服务），WS_TCP_Binary 比其他分布式技术的性能要好。这是因为该方法通过原始 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 序列化的效率高。从图 2 可以看出，ASP.NET Web 服务与 IIS_HTTP_Binary 的性能几乎相同。
使用自定义类的 GetCustomers
本节中，远程方法从数据库中检索客户记录，并将其放到 DataReader 中，然后使用 DataReader 中的数据导入一个 Customers 对象，并返回 Customers 对象。我们用 20 行和 50 行的结果集合来进行测试，以了解返回数据的数量对性能的影响。
图 3：GetCustomers(n=20)：吞吐量和滞后时间
其他选项的相对性能远远超过了 WS_TCP_Binary，因为此时 Customers 对象的封送处理成本成了重要的影响因素。本测试中，我们对一个包含 20 个客户的 Customers 对象进行序列化，而前一个测试是对整数进行了序列化。
IIS_HTTP_Binary 比 WS_HTTP_Binary 略慢，这是因为存在前面例子中所提到的额外进程跃点。请注意，ASP.NET Web 服务的性能与 IIS_HTTP_Binary 的性能非常相似。
随着数据不断增多，WS_TCP_SOAP 的性能明显下降，现在与 WS_HTTP_SOAP 和 IIS_HTTP_SOAP 相当。原因是此时大部分时间都用于序列化数据上，它成为影响性能的主要因素。
图 4：GetCustomers(n=50)：吞吐量和滞后时间
注意：
- ASMX_SOAPExtn：使用 SOAPExtension 解决 ASP.NET 的缓冲问题。
从图 4 可见，随着数据量的增大，WS_TCP_Binary 和其他选项之间的性能差异进一步缩小。
请注意，ASP.NET Web 服务已落后于 IIS_HTTP_Binary。原因是 ASP.NET 中存在大量的缓冲信息，该问题将在下个版本中得到更正。缓冲问题解决后，ASMX 选项将与 IIS_HTTP_Binary 一致（正如前面测试中所看到的）。
使用 SOAPExtension 可解决缓冲问题，这是因为它可以在 XmlSerializer 和网络间提供一些缓冲。如图所示，ASMX_SOAPExtn 选项（使用已实现的 SOAPExtension）显著改进了 ASMX 选项的性能，并仅次于 IIS_HTTP_Binary。SOAPExtension 包含在用可下载的 .NET 示例代码构建分布式应用程序中。
WS_TCP_SOAP、WS_HTTP_SOAP 和 IIS_HTTP_SOAP 性能相近，其中 WS_TCP_SOAP 稍快一些。
使用 DataSet 的 GetCustomers
在下一组测试中，远程方法从 DataSet 中的数据库检索客户记录，并返回到客户端。
图 5：GetCustomers(n=20)：吞吐量和滞后时间
由于此处数据集封送处理需要的系统开销成为重要因素，WS_TCP_Binary 和其他方法之间的性能差别已逐渐减小。
IIS_HTTP_Binary 略快于 WS_HTTP_Binary。与数据封送处理成本相比，后者的额外进程跃点成本可以忽略不计。
请注意，ASP.NET Web 服务的性能已下降很多，以致与 WS_TCP_SOAP、WS_HTTP_SOAP 和 IIS_HTTP_SOAP 的性能相近。此性能下降主要归因于两个已知的 ASP.NET 问题，这些问题将在下一版本中更正。一个是前面讨论过的缓冲问题，另一个则与 ASP.NET 中的 DataSet 序列化有关。这些问题解决后，ASP.NET Web 服务就接近 IIS_HTTP_Binary 了。通过解决大量信息的缓冲问题，ASMX_SOAPExtn 显著改进了 ASMX（如图 5 所示），但由于 DataSet 序列化问题的存在，性能仍有所降低。
图 6：GetCustomers(n=50)：吞吐量和滞后时间
由于该数据集比上一个测试中的数据集大，WS_TCP_Binary 与其他方法之间的性能差异明显缩小。可以看到，WS_HTTP_SOAP 和 IIS_HTTP_SOAP 的性能非常接近。
由于存在前面讨论过的已知问题，ASP.NET Web 服务方法越发落后。请注意，仅仅解决了缓冲问题，ASMX_SOAPExtn 就显著改进了 ASMX。
小结
正如以上测试所示，ASP.NET Web 服务和 .NET Remoting 的各种设计选项花费的系统开销差别很大，因此性能差别很明显。传递数据的大小也是一个重要的影响因素，可以使其他设计选项之间的差别成倍增加。本次比较只包括无状态的同步远程过程调用，不包括影响分布式应用程序性能的其他重要性能因素，如身份验证、授权及数据保密等。
尽管 .NET Remoting 基础结构和 ASP.NET Web 服务均可实现进程间通信，但它们的专业程度和灵活性各具特色，可以满足不同层次的目标用户。如果您的应用程序需要与其他平台或操作系统进行互操作，最好使用 ASP.NET Web 服务，因为它们支持 SOAP Section 5 和 Document/Literal，因而灵活性更好。另一方面，当您需要更丰富的面向对象的编程模型时，请使用 .NET Remoting。有关详细信息，请参阅 ASP.NET Web 服务还是 .NET Remoting：如何选择。在性能是主要要求而不太关心安全性和进程生命周期的方案中，可以选择 .NET Remoting TCP/二进制；但是请记住，当使用 IIS 主机实现时，可以通过向系统中添加更多的计算机来改善性能，而 .NET Remoting TCP/二进制实现则不能。
