性能比較：.NET Remoting與ASP.NET Web服務(wù)

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

性能比較：.NET Remoting與ASP.NET Web服務(wù)

－－使用 Microsoft .NET 建立分布式應(yīng)用程序

適用于：
  
Microsoft? .NET Remoting
  
Microsoft? ASP.NET Web 服務(wù)

摘要：本文對(duì) Microsoft ASP.NET Web 服務(wù)與 Microsoft .NET Remoting 的相對(duì)性能進(jìn)行比較。Microsoft ASP.NET Web 服務(wù)的互操作性最好，并完全支持 HTTP 上的 WSDL 和 SOAP；而 Microsoft .NET Remoting 可實(shí)現(xiàn)公共語(yǔ)言運(yùn)行庫(kù)類型系統(tǒng)的高保真，并支持其他數(shù)據(jù)格式和通信通道。

從 MSDN Code Center 下載 BDADotnet.msi 示例代碼（英文）。

簡(jiǎn)介

ASP.NET Web 服務(wù)和 .NET Remoting 為分布式應(yīng)用程序中的進(jìn)程間通信提供了一整套設(shè)計(jì)選項(xiàng)。通常，ASP.NET Web 服務(wù)的互操作性最好，并完全支持 HTTP 上的 WSDL 和 SOAP；而 .NET Remoting 可實(shí)現(xiàn)公共語(yǔ)言運(yùn)行庫(kù)類型系統(tǒng)的高保真，并支持其他數(shù)據(jù)格式和通信通道。有關(guān)詳細(xì)信息，請(qǐng)參閱 ASP.NET Web 服務(wù)還是 .NET Remoting：如何選擇。

本文主要對(duì)這兩項(xiàng)技術(shù)的相對(duì)性能進(jìn)行比較。

ASP.NET Web 服務(wù)

ASP.NET 提供以 Microsoft? IIS 作為宿主的基礎(chǔ)結(jié)構(gòu)，支持 SOAP、XML 和 WSDL 等行業(yè)標(biāo)準(zhǔn)。盡管 .NET Remoting 也支持 IIS 宿主和 HTTP 上的 SOAP，但 ASP.NET 卻可提供最高級(jí)別的 SOAP 互操作性，包括對(duì) SOAP Section 5 和 Document/Literal 的支持。

ASP.NET 可以充分利用 IIS 具有的功能，如安全性和日志記錄。IIS 宿主也很強(qiáng)大，因?yàn)樗梢栽? Aspnet_wp.exe 終止后重新生成它。此外，由于 ASP.NET Web 服務(wù)的服務(wù)器和客戶端的配置都已簡(jiǎn)化，因此與使用 .NET Remoting 提供的服務(wù)相比，它的創(chuàng)建和使用更為容易。

有關(guān)詳細(xì)信息，請(qǐng)參閱 .NET Framework Developer's Guide 中的 Building XML Web Services Using ASP.NET（英文）。

.NET Remoting

.NET Remoting 更具通用性和擴(kuò)展性，允許在使用不同傳輸協(xié)議和序列化格式的對(duì)象間進(jìn)行通信。它支持二進(jìn)制、SOAP、自定義格式以及 TCP、HTTP 和自定義協(xié)議。支持多對(duì)象創(chuàng)建和生存期模式，包括 Singleton、SingleCall 和 Client-Activated。Remoting 需要一個(gè)主機(jī)進(jìn)程，可以是 IIS、Microsoft? Windows 服務(wù)或用 .NET 編寫的可執(zhí)行文件。

在具有 ASP.NET 的 IIS 中宿主使用 SOAP 格式化程序的 .NET Remoting 對(duì)象時(shí)，該對(duì)象可以公開為 XML Web 服務(wù)。由于有效負(fù)載以 HTTP 上的 SOAP 進(jìn)行編碼，因此任何支持 SOAP 編碼格式的客戶端均可通過 Internet 訪問該對(duì)象。使用 HTTP 協(xié)議的另一個(gè)優(yōu)點(diǎn)是它通常可以暢通無(wú)阻地通過大多數(shù)防火墻。TCP 通道和二進(jìn)制格式化程序可以部署在服務(wù)器和客戶端均運(yùn)行 .NET Framework 的 Intranet 環(huán)境中。此方法的性能最佳，因?yàn)樵谑褂迷继捉幼滞ㄟ^網(wǎng)絡(luò)傳輸數(shù)據(jù)時(shí)使用了效率高于 HTTP 的自定義協(xié)議。盡管此方法在封閉環(huán)境中可以提供出眾的性能，但它不能部署于客戶端未運(yùn)行 .NET Framework 的跨平臺(tái)方案。

IIS 主機(jī)使用安全套接字層 (SSL) 為網(wǎng)絡(luò)級(jí)保護(hù)提供安全通信，您也可以利用 IIS 和 ASP.NET 身份驗(yàn)證和授權(quán)。TCP 通道以及不通過 IIS 宿主的 HTTP 通道不支持安全套接字傳輸，因此其數(shù)據(jù)以明文形式傳輸。如果使用的是 TCP 通道或由非 IIS 進(jìn)程宿主的 HTTP 通道，則您需要負(fù)責(zé)實(shí)現(xiàn)其安全性。

有關(guān)更多詳細(xì)信息，請(qǐng)參閱 .NET Framework Developer's Guide 中的 .NET Remoting Overview（英文）。

測(cè)試方案

分布式應(yīng)用程序中進(jìn)程間通信的性能取決于以下因素：

用于跨遠(yuǎn)程邊界的應(yīng)用程序間傳輸信息的通道（包括 TCP 和 HTTP）占用的系統(tǒng)開銷量。TCP 套接字比 HTTP 更為有效。

另一個(gè)因素是序列化。序列化流可以通過 XML、SOAP 或壓縮二進(jìn)制表示法進(jìn)行編碼。ASP.NET Web 服務(wù)使用 XMLSerializer 類將對(duì)象序列化為 XML 流，XML 流的速度非?？?，但由于存在 XML 分析，因而需要一定的系統(tǒng)開銷。Remoting 分別使用 BinaryFormatter 和 SOAPFormatter 將對(duì)象序列化為二進(jìn)制格式和 SOAP 格式。由于這些格式化程序使用反射，因而對(duì)于引用對(duì)象很快，但對(duì)于必須經(jīng)過裝箱或取消裝箱來(lái)通過反射 API 傳遞的值類型則較慢。此外，SOAPFormatter 還需要額外的系統(tǒng)開銷以生成編碼的 SOAP 消息。

本比較中使用的測(cè)試基于訪問客戶和訂單數(shù)據(jù)的普通業(yè)務(wù)方案。為使測(cè)試盡可能符合實(shí)際，數(shù)據(jù)庫(kù)中包含 100,000 多行客戶帳戶。數(shù)據(jù)位于 Microsoft? SQL Server? 2000 數(shù)據(jù)庫(kù)中，并使用 SQL Server .NET 數(shù)據(jù)提供程序連接到 SQL Server。

性能比較中使用了以下方法：

GetOrderStatus
GetOrderStatus 方法接受 OrderId 并返回表示訂單狀態(tài)的整數(shù)。

GetCustomers
GetCustomers 方法接受 CustomerId 和參數(shù)以指定想要讀取的客戶行數(shù)目，并讀取 CustomerId 大于傳遞給 Web 服務(wù)方法的 CustomerId 的前 n 行。

測(cè)試過程中，我們通過具有不同頁(yè)面大?。?0 和 50）逐頁(yè)提取小客戶行集合。

測(cè)試工具和策略

測(cè)試中，ASPX Web 頁(yè)調(diào)用包含測(cè)試代碼的遠(yuǎn)程對(duì)象。盡管直接測(cè)試該技術(shù)（而不是通過在 Web 服務(wù)器后端測(cè)試）可以得到更好的絕對(duì)性能，但是在無(wú)狀態(tài)環(huán)境中測(cè)試對(duì)于普通應(yīng)用程序方案來(lái)說(shuō)更符合實(shí)際。另外，有很多測(cè)試工具可以通過提供多線程測(cè)試和可靠的性能統(tǒng)計(jì)對(duì) Web 頁(yè)進(jìn)行適當(dāng)?shù)膹?qiáng)度測(cè)試。

在本測(cè)試中，我們使用了 Microsoft 應(yīng)用程序中心測(cè)試 (ACT)。它可以對(duì) Web 服務(wù)器進(jìn)行強(qiáng)度測(cè)試，分析 Web 應(yīng)用程序（包括 ASPX 頁(yè)及其使用的組件）的性能和可伸縮性問題。有關(guān)如何創(chuàng)建和運(yùn)行測(cè)試的詳細(xì)信息，請(qǐng)參閱 ACT 文檔。通過打開到服務(wù)器的多個(gè)連接并迅速發(fā)送 HTTP 請(qǐng)求，應(yīng)用程序中心測(cè)試可以模擬一大組用戶。它還允許我們建立實(shí)際的測(cè)試方案，我們可以在方案中使用一組隨機(jī)參數(shù)值調(diào)用同一個(gè)方法。此功能很重要，因?yàn)橛脩舨豢赡軙?huì)使用相同的參數(shù)值反復(fù)調(diào)用同一個(gè)方法。另一個(gè)有用的功能是，應(yīng)用程序中心測(cè)試可以記錄測(cè)試結(jié)果，從而提供有關(guān) Web 應(yīng)用程序性能的最重要的信息。

如前所述，遠(yuǎn)程對(duì)象有兩種激活方法 - 服務(wù)器激活和客戶端激活。服務(wù)器直接控制服務(wù)器激活對(duì)象的生存期。服務(wù)器激活對(duì)象有兩種激活模式 - Singleton 和 SingleCall。Singleton 類型不能同時(shí)運(yùn)行一個(gè)以上的實(shí)例。所有客戶端請(qǐng)求由一個(gè)實(shí)例提供服務(wù)，因此，使用該激活模式可以維護(hù)客戶端之間的狀態(tài)。另一方面，對(duì)于 SingleCall 類型而言，每個(gè)客戶端請(qǐng)求由一個(gè)不同的實(shí)例來(lái)服務(wù)?？蛻舳思せ顚?duì)象在服務(wù)器上創(chuàng)建，但這些對(duì)象的生存期卻由調(diào)用應(yīng)用程序域控制。使用此模式可以維護(hù)來(lái)自同一客戶端的請(qǐng)求間的狀態(tài)。ASP.NET 僅支持 SingleCall（即每個(gè)請(qǐng)求由一個(gè)新實(shí)例提供服務(wù)），如果服務(wù)是有狀態(tài)的，則必須使用 cookie 和 SessionState 或自定義 SOAP 標(biāo)頭對(duì)其進(jìn)行管理。在已經(jīng)執(zhí)行的所有用于比較各種遠(yuǎn)程選項(xiàng)的測(cè)試中，使用了 SingleCall 模式進(jìn)行合理比較。

盡管 ASP.NET Web 服務(wù)支持 SOAP、HTTP-GET 和 HTTP-POST 選項(xiàng)，但為了保持一致性，測(cè)試中僅使用了 SOAP 選項(xiàng)。

HTTP/1.1 建議任何單個(gè)客戶端與單個(gè)服務(wù)器之間至多建立兩個(gè)連接。因此，當(dāng)使用 HTTP 協(xié)議進(jìn)行通信（如使用 HTTP 通道和 ASP.NET）時(shí)，在默認(rèn)情況下，該協(xié)議在任何給定時(shí)間只打開兩個(gè)到給定服務(wù)器的連接；而 TCP 通道可根據(jù)向服務(wù)器發(fā)出請(qǐng)求的線程數(shù)目，打開多個(gè)連接。為了模擬多個(gè)向遠(yuǎn)程對(duì)象發(fā)送同步請(qǐng)求的客戶端，我們使用客戶端配置文件將每個(gè)客戶端與服務(wù)器的連接數(shù)目由默認(rèn)值 2 改為 100：

使用 HTTP 通道進(jìn)行遠(yuǎn)程通信時(shí) - 使用客戶端 .config 文件中的 clientConnectionLimit 屬性：

<system.runtime.remoting>
   <application>
         ...
    <channels>
      <channel ref="http" clientConnectionLimit="100">
         <clientProviders>
            <formatter ref="soap" />
         </clientProviders>
      </channel>
   </channels>
      </application>
 </system.runtime.remoting>

對(duì)于 ASP.NET Web 服務(wù)，使用客戶端 .config 文件中 <system.net> 中的 maxConnection 屬性：

    <system.net>
        <connectionManagement>
            <add address="*"
                 maxconnection="100"
            />
        </connectionManagement>
    </system.net>
由于允許與“l(fā)ocalhost”（即客戶端和服務(wù)器在同一計(jì)算機(jī)上）建立無(wú)限多個(gè) HTTP 連接，因此不需要更改配置文件。

計(jì)算機(jī)配置

下表提供了用于執(zhí)行測(cè)試的測(cè)試臺(tái)配置的簡(jiǎn)單摘要。

表 1：客戶端計(jì)算機(jī)配置

客戶端數(shù)量 計(jì)算機(jī)/CPU CPU 數(shù)量 內(nèi)存 硬盤 軟件 1 Compaq Proliant 1130 MHz 2 1GB 16.9 GB

• Windows 2000 Advance Server SP 2
• 應(yīng)用程序中心測(cè)試

表 2：Web 服務(wù)器配置

服務(wù)器數(shù)量 計(jì)算機(jī)/CPU CPU 數(shù)量 內(nèi)存 硬盤 軟件 3 Compaq Proliant 1000 MHz 2 1 GB 16.9 GB

• Windows 2000 Advance Server SP 2
• .NET Framework SP1 發(fā)行版本

表 3：應(yīng)用程序服務(wù)器配置

服務(wù)器數(shù)量 計(jì)算機(jī)/CPU CPU 數(shù)量 內(nèi)存 硬盤 軟件 1 Compaq Proliant 1126 MHz 2 1 GB 16.9 GB

• Windows 2000 Advance Server SP 2
• .NET Framework SP1 發(fā)行版本

表 4：數(shù)據(jù)庫(kù)服務(wù)器配置

服務(wù)器數(shù)量 計(jì)算機(jī)/CPU CPU 數(shù)量 內(nèi)存 硬盤 軟件 1 Compaq Proliant 700 MHz 4 4 GB 18 GB

• Windows 2000 Advance Server SP 2
• SQL Server Enterprise Edition SP 2

性能測(cè)試結(jié)果

吞吐量和滯后時(shí)間是關(guān)鍵的性能指標(biāo)。對(duì)于給定數(shù)量的返回?cái)?shù)據(jù)，吞吐量是指單位時(shí)間（通常是 1 秒）內(nèi)處理的客戶端請(qǐng)求數(shù)量。因?yàn)閺目捎眯越嵌葋?lái)看，吞吐量在某一響應(yīng)時(shí)間達(dá)到峰值是不能接受的，因此我們跟蹤了滯后時(shí)間，利用由應(yīng)用程序中心測(cè)試為每個(gè)運(yùn)行的測(cè)試生成的報(bào)告，將其作為響應(yīng)時(shí)間進(jìn)行測(cè)定。

跨計(jì)算機(jī)方案

在跨計(jì)算機(jī)方案中，遠(yuǎn)程客戶端和遠(yuǎn)程對(duì)象位于不同的計(jì)算機(jī)中。ACT 客戶端向 ASPX Web 頁(yè)發(fā)送請(qǐng)求，該頁(yè)隨后調(diào)用遠(yuǎn)程對(duì)象中的方法。

圖 1：跨計(jì)算機(jī)方案

如圖 1 所示，測(cè)試是在 Web 服務(wù)器后端執(zhí)行的，并存在數(shù)據(jù)庫(kù)訪問以及到外部計(jì)算機(jī)的網(wǎng)絡(luò)躍點(diǎn)，從而增加了額外的系統(tǒng)開銷。因此，生成的吞吐量和滯后時(shí)間性能值僅作為比較這兩項(xiàng)技術(shù)的基礎(chǔ)，它們不代表絕對(duì)性能。使用 ASP.NET Web 服務(wù)和 .NET Remoting 構(gòu)建的分布式系統(tǒng)的精確吞吐量和滯后時(shí)間取決于所使用的體系結(jié)構(gòu)。

GetOrderStatus

當(dāng)從數(shù)據(jù)庫(kù)中獲得單個(gè)值后，我們將對(duì)各種技術(shù)的表現(xiàn)進(jìn)行比較。

圖 2：GetOrderStatus：吞吐量和滯后時(shí)間

注意：

ASMX：ASP.NET Web 服務(wù)

所有其他選項(xiàng)表示不同的 .NET Remoting 配置。

在所有其他選項(xiàng)中，名稱隱含了主機(jī)、使用的傳輸協(xié)議和格式，即 Host_TransaportProtocol_Format。

“WS”即 Windows Service（Windows 服務(wù)）的縮寫，它托管了遠(yuǎn)程類型。

IIS_HTTP_Binary/SOAP 托管于帶有 ASP.NET 的 IIS 中。

如圖 2 所示（該對(duì)象配置為使用 TCP 通道和二進(jìn)制格式化程序，主機(jī)是 Windows 服務(wù)），WS_TCP_Binary 比其他分布式技術(shù)的性能要好。這是因?yàn)樵摲椒ㄍㄟ^原始 TCP 套接字傳輸二進(jìn)制數(shù)據(jù)（比 HTTP 的效率高），且數(shù)據(jù)不需要編碼/解碼，因而降低了系統(tǒng)開銷?？梢钥吹?，WS_TCP_Binary 和最慢的方法之間存在約 60% 的性能差距。

盡管 IIS_HTTP_Binary 與 WS_HTTP_Binary 產(chǎn)生的二進(jìn)制有效負(fù)載相同，但它的速度較慢，原因是存在著從 IIS (Inetinfo.exe) 向 Aspnet_wp.exe 的額外進(jìn)程躍點(diǎn)。IIS_HTTP_SOAP 和 WS_HTTP_SOAP 之間的性能差別也由此造成。

WS_HTTP_Binary 和 WS_TCP_SOAP 的性能幾乎相同。盡管前者有 HTTP 分析方面的額外系統(tǒng)開銷，后者有 SOAP 分析方面的額外系統(tǒng)開銷，但在本例中 HTTP 分析的系統(tǒng)開銷與 SOAP 分析的系統(tǒng)開銷幾乎相同。

ASP.NET Web 服務(wù)的性能優(yōu)于 IIS_HTTP_SOAP 和 WS_HTTP_SOAP，因?yàn)?ASP.NET XML 序列化比 .NET Remoting SOAP 序列化的效率高。從圖 2 可以看出，ASP.NET Web 服務(wù)與 IIS_HTTP_Binary 的性能幾乎相同。

使用自定義類的 GetCustomers

本節(jié)中，遠(yuǎn)程方法從數(shù)據(jù)庫(kù)中檢索客戶記錄，并將其放到 DataReader 中，然后使用 DataReader 中的數(shù)據(jù)導(dǎo)入一個(gè) Customers 對(duì)象，并返回 Customers 對(duì)象。我們用 20 行和 50 行的結(jié)果集合來(lái)進(jìn)行測(cè)試，以了解返回?cái)?shù)據(jù)的數(shù)量對(duì)性能的影響。

圖 3：GetCustomers(n=20)：吞吐量和滯后時(shí)間

其他選項(xiàng)的相對(duì)性能遠(yuǎn)遠(yuǎn)超過了 WS_TCP_Binary，因?yàn)榇藭r(shí) Customers 對(duì)象的封送處理成本成了重要的影響因素。本測(cè)試中，我們對(duì)一個(gè)包含 20 個(gè)客戶的 Customers 對(duì)象進(jìn)行序列化，而前一個(gè)測(cè)試是對(duì)整數(shù)進(jìn)行了序列化。

IIS_HTTP_Binary 比 WS_HTTP_Binary 略慢，這是因?yàn)榇嬖谇懊胬又兴岬降念~外進(jìn)程躍點(diǎn)。請(qǐng)注意，ASP.NET Web 服務(wù)的性能與 IIS_HTTP_Binary 的性能非常相似。

隨著數(shù)據(jù)不斷增多，WS_TCP_SOAP 的性能明顯下降，現(xiàn)在與 WS_HTTP_SOAP 和 IIS_HTTP_SOAP 相當(dāng)。原因是此時(shí)大部分時(shí)間都用于序列化數(shù)據(jù)上，它成為影響性能的主要因素。

圖 4：GetCustomers(n=50)：吞吐量和滯后時(shí)間

注意：

ASMX_SOAPExtn：使用 SOAPExtension 解決 ASP.NET 的緩沖問題。

從圖 4 可見，隨著數(shù)據(jù)量的增大，WS_TCP_Binary 和其他選項(xiàng)之間的性能差異進(jìn)一步縮小。

請(qǐng)注意，ASP.NET Web 服務(wù)已落后于 IIS_HTTP_Binary。原因是 ASP.NET 中存在大量的緩沖信息，該問題將在下個(gè)版本中得到更正。緩沖問題解決后，ASMX 選項(xiàng)將與 IIS_HTTP_Binary 一致（正如前面測(cè)試中所看到的）。

使用 SOAPExtension 可解決緩沖問題，這是因?yàn)樗梢栽?XmlSerializer 和網(wǎng)絡(luò)間提供一些緩沖。如圖所示，ASMX_SOAPExtn 選項(xiàng)（使用已實(shí)現(xiàn)的 SOAPExtension）顯著改進(jìn)了 ASMX 選項(xiàng)的性能，并僅次于 IIS_HTTP_Binary。SOAPExtension 包含在用可下載的 .NET 示例代碼構(gòu)建分布式應(yīng)用程序中。

WS_TCP_SOAP、WS_HTTP_SOAP 和 IIS_HTTP_SOAP 性能相近，其中 WS_TCP_SOAP 稍快一些。

使用 DataSet 的 GetCustomers

在下一組測(cè)試中，遠(yuǎn)程方法從 DataSet 中的數(shù)據(jù)庫(kù)檢索客戶記錄，并返回到客戶端。

圖 5：GetCustomers(n=20)：吞吐量和滯后時(shí)間

由于此處數(shù)據(jù)集封送處理需要的系統(tǒng)開銷成為重要因素，WS_TCP_Binary 和其他方法之間的性能差別已逐漸減小。

IIS_HTTP_Binary 略快于 WS_HTTP_Binary。與數(shù)據(jù)封送處理成本相比，后者的額外進(jìn)程躍點(diǎn)成本可以忽略不計(jì)。

請(qǐng)注意，ASP.NET Web 服務(wù)的性能已下降很多，以致與 WS_TCP_SOAP、WS_HTTP_SOAP 和 IIS_HTTP_SOAP 的性能相近。此性能下降主要?dú)w因于兩個(gè)已知的 ASP.NET 問題，這些問題將在下一版本中更正。一個(gè)是前面討論過的緩沖問題，另一個(gè)則與 ASP.NET 中的 DataSet 序列化有關(guān)。這些問題解決后，ASP.NET Web 服務(wù)就接近 IIS_HTTP_Binary 了。通過解決大量信息的緩沖問題，ASMX_SOAPExtn 顯著改進(jìn)了 ASMX（如圖 5 所示），但由于 DataSet 序列化問題的存在，性能仍有所降低。

圖 6：GetCustomers(n=50)：吞吐量和滯后時(shí)間

由于該數(shù)據(jù)集比上一個(gè)測(cè)試中的數(shù)據(jù)集大，WS_TCP_Binary 與其他方法之間的性能差異明顯縮小。可以看到，WS_HTTP_SOAP 和 IIS_HTTP_SOAP 的性能非常接近。

由于存在前面討論過的已知問題，ASP.NET Web 服務(wù)方法越發(fā)落后。請(qǐng)注意，僅僅解決了緩沖問題，ASMX_SOAPExtn 就顯著改進(jìn)了 ASMX。

小結(jié)

正如以上測(cè)試所示，ASP.NET Web 服務(wù)和 .NET Remoting 的各種設(shè)計(jì)選項(xiàng)花費(fèi)的系統(tǒng)開銷差別很大，因此性能差別很明顯。傳遞數(shù)據(jù)的大小也是一個(gè)重要的影響因素，可以使其他設(shè)計(jì)選項(xiàng)之間的差別成倍增加。本次比較只包括無(wú)狀態(tài)的同步遠(yuǎn)程過程調(diào)用，不包括影響分布式應(yīng)用程序性能的其他重要性能因素，如身份驗(yàn)證、授權(quán)及數(shù)據(jù)保密等。

盡管 .NET Remoting 基礎(chǔ)結(jié)構(gòu)和 ASP.NET Web 服務(wù)均可實(shí)現(xiàn)進(jìn)程間通信，但它們的專業(yè)程度和靈活性各具特色，可以滿足不同層次的目標(biāo)用戶。如果您的應(yīng)用程序需要與其他平臺(tái)或操作系統(tǒng)進(jìn)行互操作，最好使用 ASP.NET Web 服務(wù)，因?yàn)樗鼈冎С?SOAP Section 5 和 Document/Literal，因而靈活性更好。另一方面，當(dāng)您需要更豐富的面向?qū)ο蟮木幊棠Ｐ蜁r(shí)，請(qǐng)使用 .NET Remoting。有關(guān)詳細(xì)信息，請(qǐng)參閱 ASP.NET Web 服務(wù)還是 .NET Remoting：如何選擇。在性能是主要要求而不太關(guān)心安全性和進(jìn)程生命周期的方案中，可以選擇 .NET Remoting TCP/二進(jìn)制；但是請(qǐng)記住，當(dāng)使用 IIS 主機(jī)實(shí)現(xiàn)時(shí)，可以通過向系統(tǒng)中添加更多的計(jì)算機(jī)來(lái)改善性能，而 .NET Remoting TCP/二進(jìn)制實(shí)現(xiàn)則不能。