摘要：本文通過比較事務處理模型，包括數據庫事務處理、Microsoft ADO.NET 手動事務處理和使用 Microsoft SQL Server 2000 數據庫的通用應用程序方案中的 ADO.NET 自動事務處理，重點介紹影響性能、可伸縮性和可維護性的事務處理控件的性能部分。

目錄

• 簡介
• 體系結構選項
• 測試方案
• 測試工具和策略
• 計算機配置
• 性能測試結果
• 總結

簡介

事務處理控件的體系結構選擇影響到性能、可伸縮性和可維護性。本文通過比較各種事務處理模型，包括數據庫事務處理、Microsoft? ADO.NET 手動事務處理和使用 Microsoft SQL Server? 2000 數據庫的通用應用程序方案中的 ADO.NET 自動事務處理等模型的相關性能，重點介紹這些選擇的性能部分。

有關此處所比較的技術方面的代碼示例，請參閱 Transaction Control（英文）中的相關文章。

體系結構選項

事務處理控件模型包括數據庫事務處理、手動事務處理和自動事務處理。雖然這些模型完成的任務相同，即維護某個事務處理范圍內資源之間的一致性，但它們又各有優缺點，因此用途也各不相同。

數據庫事務處理
數據庫事務處理是在 Transact-SQL 中實現的，Transact-SQL 將所需的操作打包在 BEGIN TRANSACTION 和 COMMIT/ROLLBACK TRANSACTION 語句中。

手動事務處理
手動控制事務處理范圍是通過使用一組 ADO.NET 對象進行的，使用明確的指令開始和結束事務處理。

自動事務處理
在 Microsoft Windows? 2000 組件服務 (COM+) 中注冊 .NET 類，以便參與事務處理。該類具有聲明性屬性的標記，指定該類參與事務處理的方式?！?/P>

測試方案

為了比較事務處理模型，我們使用了一個方法，在數據庫的相應表中插入訂單標頭和詳細信息。如果任何插入操作失敗，我們將事務處理恢復到原始狀態。如果所有插入操作成功，則提交事務處理。

為了使測試盡可能符合實際情況，加載的數據庫中包含了 10 萬行客戶帳戶，100 萬行訂單（每個客戶 10 個訂單）和 500 萬個訂單詳細信息（每個訂單 5 個詳細信息）。這些數據位于 SQL Server 2000 數據庫和 SQL Server .NET 數據提供程序中，用于連接 SQL Server。此處比較的某些方法使用了 SQL Server 2000 的 XML 功能。

InsertOrder

InsertOrder 方法接受代表一個訂單和多個詳細信息的數據，然后將數據插入到數據庫中相應的 Order 和 OrderDetails 表中，作為該事務處理的一部分。

測試工具和策略

在我們的測試中，一個 ASPX Web 頁調用了一個包含測試代碼的 .NET 程序集。如果直接測試事務處理控件技術，而不是通過 Web 服務器，我們可以獲得更好的絕對性能，然而，對通用應用程序方案而言，在無狀態環境中進行測試更具現實意義。另外，有很多測試工具可以對提供多線程測試的 Web 頁進行適當地強度測試。

為達到測試目的，我們使用了 Microsoft 應用程序中心測試 (ACT)。它可以對 Web 服務器進行強度測試，分析 Web 應用程序（包括 ASP 頁及其使用的組件）的性能和可伸縮性問題。有關如何創建和運行測試的詳細信息，請參閱 ACT documentation（英文）。通過打開到服務器的多個連接并迅速發送 HTTP 請求，應用程序中心測試可以模擬一大組用戶。它還允許我們建立實際的測試方案，我們可以在方案中使用一組隨機參數值調用同一個方法。此功能很重要，這樣用戶就不必使用相同的參數值反復調用同一個方法。另一個有用的功能是，應用程序中心測試可以記錄測試結果，從而提供有關 Web 應用程序性能的最重要的信息。

根據業務需求不同，應用程序可能在不同的事務處理隔離級別上運行。隔離是指一個事務處理必須和其他事務處理分離的程度。隔離級別越高，越能保證數據的一致性，但可能會嚴重影響應用程序的伸縮能力。降低隔離級別可以增強應用程序的可伸縮性，但卻不能保證數據的準確性。Microsoft SQL Server 2000 支持四種隔離級別：READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIAZABLE。默認情況下，它在 READ COMMITTED 隔離級別下運行。有關詳細信息，請參閱 Microsoft SQL Server 2000 documentation（英文）。Windows 2000 上運行的 COM+（1.0 版）只支持 SERIALIAZABLE 隔離，即最高程度的隔離。這樣高的數據保護級別大大影響了性能。（注意：與 Microsoft Windows .NET Server（目前最高版本是 Beta 3）一同發行的 COM+ 1.5 允許對事務處理組件的隔離級別進行配置。）為了對事務處理模型進行客觀的比較，我們在 SERIALIAZABLE 隔離級別上運行事務處理。

計算機配置

下表提供了用于執行測試的測試臺配置的簡單摘要。

表 1：客戶端計算機配置

表 2：Web 服務器配置

表 3：數據庫服務器配置　

性能測試結果

吞吐量和滯后時間是關鍵的性能指標。對于給定數量的返回數據，吞吐量是指單位時間（通常是 1 秒）內處理的客戶端請求數量。因為從可用性角度來看，吞吐量在某一響應時間達到峰值是不能接受的，因此我們跟蹤了滯后時間，利用由 ACT 為每個運行的測試生成的報告，將其作為響應時間進行測定，并在響應時間超過 1 秒時立即停止某個給定方法的測試。

使用 OPENXML 執行 InsertOrder

在第一組測試中，訂單和訂單詳細信息從 DataSet 表中以 XML 格式傳遞到一個 Microsoft SQL Server 2000 存儲過程中。存儲過程中的 Transact-SQL 代碼使用 OPENXML 方法，通過一次數據庫往返將相應信息插入到 Order 和 OrderDetails 表中。測試首先運行一個包含 10 個詳細信息的訂單。


圖 1：InsertOrder_OpenXml(Order=1, Details=10)
　

注意

• 在 DatabaseTxn 方法中，存儲過程將操作打包在 BEGIN TRANSACTION 和 COMMIT/ROLLBACK TRANSACTION 語句中。
   
• 在 ManualTxn 方法中，使用 ADO.NET SQLTransaction 對象來控制事務處理。
  　
• 在 ManualTxn_COM+_IP 和 ManualTxn_COM+_OP 中，都是使用 ADO.NET SQLTransaction 對象來控制事務處理，而程序集則由 COM+ 分別配置為庫和服務器程序包。
  　
• 包含 AutomaticTxn 和 AutCompleteTxn 實現的 .NET 程序集使用 COM+ 進行注冊。在 AutomaticTxn 中，我們顯式提交或中止事務處理，而在 AutoCompleteTxn 中，則由 .NET 程序集來確定提交或中止當前事務處理。
   
• 在 AutomaticTxn_IP 和 AutoCompleteTxn_IP 中，包含程序集的 COM+ 應用程序是一個由庫激活的應用程序，所以該應用程序在創建它的客戶端進程中運行。
  　
• 在 AutomaticTxn_OP 和 AutoCompleteTxn_OP 中，包含程序集的 COM+ 應用程序是一個由服務器激活的應用程序，所以該應用程序在代理進程 (dllhost.exe) 中運行。 如圖 1 所示，DatabaseTxn、ManualTxn 和 ManualTxn_COM+_IP 方法提供了類似的性能，只是 DatabaseTxn 方法的吞吐量比手動事務處理模型略高一些。這是因為 ADO.NET 手動事務處理需要執行額外的數據庫往返操作以開始和結束事務處理。

ManualTxn_COM+_IP 產生的 COM+ 相互操作非常少，因為此方法不使用任何 COM+ 服務，這也是它和 ManualTxn 具有非常類似的行為的原因，在 ManualTxn 中，根本沒有涉及到 COM+。

如果將 ManualTxn 和 ManualTxn_COM+_IP 與 AutomaticTxn_IP 進行比較，您會發現自動事務處理平均要慢約 30％。這是因為使用分布式事務協調器 (DTC) 設置事務處理的成本要比在事務處理中完成所有工作（11 次插入）的成本大。AutomaticTxn_IP 還涉及到一個上下文方法調用，需要進行上下文轉換，因而產生了額外的成本。

AutomaticTxn_IP 提供的性能比 ManualTxn_COM+_OP 和 AutomaticTxn_OP 要好，因為 AutomaticTxn_IP 中的庫程序包可以使程序集在調用應用程序進程（本例中是 as.net_wp.exe）內部運行，從而避免了封送處理。因為無需數據封送，AutomaticTxn_IP 中的總體成本（包括 DTC 成本）要比 ManualTxn_COM+_OP 少，這也是 AutomaticTxn_IP 在性能方面比 ManualTxn_COM+_OP 略勝一籌的原因。

可以看到，AutoCompleteTxn_IP 和 AutoCompleteTxn_OP AutoComplete 版本分別與 AutomaticTxn_IP 和 AutomaticTxn_OP 版本的運行狀況類似。使用 AutoComplete 提交的缺點是，它在方法成功返回并確定進行提交時，由于事務處理要釋放服務器資源而延長了時間，因而可能會降低應用程序的性能。另外，當事務處理失敗時，它不允許用戶在需要時發出用戶友好消息。



圖 2：InsertOrder_OpenXml(Order=1, Details=100)

當測試運行 1 個訂單和 100 個詳細信息時，各種方法之間幾乎沒有什么差別。

在吞吐量方面，數據庫事務處理模型仍然比其他方法略占一些優勢。

此測試中各個模型的性能都非常接近，這是因為在此事務處理中完成了大量工作（101 次插入）。這里的成本（例如進程間的 DTC 通信和數據封送）被分攤到整個事務處理過程中，因此變得不是那么明顯。

使用多個 DataAdapter 的 InsertOrder
在第二組測試中，我們為數據庫中的 Order 和 OrderDetails 表分別關聯了 DataAdapter。在 DataAdapter 上，為 InsertCommand 指定了存儲過程。首先調用與 Order 表對應的 DataAdapter 上的 Update 方法，它返回新插入訂單的 OrderId。然后調用與 OrderDetails 表對應的 DataAdapter 上的 Update 方法。因為 Update 方法不是以批處理方式向數據庫發送更改，因此這一技術使用了多次數據庫往返操作，以完成這些插入。

請參閱 Performance Comparison: Data Aclearcase/" target="_blank" >ccess Techniques（英文）一文，其中比較了各種數據訪問技術，包括 OPENXML 和多個 DataAdapter 方法。

測試首先運行 1 個訂單和 10 個詳細信息。



圖 3：InsertOrder_DataSet(Order=1, Details=10)

注意

在 ManualTxn 方法中，事務處理控件通過 ADO.NET SQLTransaction 對象來實現。
在 ManualTxn_COM+_IP 和 ManualTxn_COM+_OP 中，都是使用 ADO.NET SQLTransaction 對象來控制事務處理，而程序集則由 COM+ 分別配置為庫和服務器程序包。
包含 AutomaticTxn 和 AutCompleteTxn 實現的 .NET 程序集使用 COM+ 進行注冊。在 AutomaticTxn 中，我們顯式提交或中止事務處理，而在 AutoCompleteTxn 中，則由 .NET 程序集來確定提交或中止當前事務處理。
在 AutomaticTxn_IP 和 AutoCompleteTxn_IP 中，包含程序集的 COM+ 應用程序是一個由庫激活的應用程序，所以該應用程序在創建它的客戶端進程中運行。
在 AutomaticTxn_OP 和 AutoCompleteTxn_OP 中，包含程序集的 COM+ 應用程序是一個由服務器激活的應用程序，所以它在代理進程 (dllhost.exe) 中運行。
ManualTxn 和 ManualTxn_COM+_IP 的性能非常類似，這是因為與 COM+ 相互操作相關的成本很小。

AutomaticTxn_IP 與上述方法相比明顯緩慢，這是因為使用分布式事務協調器 (DTC) 設置事務處理的成本要比在事務處理中完成所有工作（11 次插入）的成本高。除了 DTC 外，AutomaticTxn_IP 中還因 COM+ 的相互操作和上下文轉換而產生了一些額外的成本，這一點我們從上面可以看到。

AutomaticTxn_IP 提供的性能要比 ManualTxn_COM+_OP 和 AutomaticTxn_OP 提供的性能好，因為在后者中，COM+ 應用程序被配置為服務器程序包，而服務器程序包在一個單獨的代理程序 (dllhost.exe) 中運行，因而需要數據封送。

正如我們所預計的那樣，AutoCompleteTxn_IP 和 AutoCompleteTxn_OP AutoComplete 版本分別與 AutomaticTxn_IP 和 AutomaticTxn_OP 版本的運行狀況類似。



圖 4：InsertOrder_DataSet(Order=1, Details=100)

與第一個測試一樣，在大型事務處理（101 次插入）中，事務處理控件模型之間的性能差別大大降低了。而且，與 DTC 和數據封送相關的成本也因大型事務處理的分攤而降低了?！?/P>

總結

每個事務處理模型在應用程序性能和代碼可維護性方面都各有側重，因此它們適用于不同的方案。

運行存儲過程中實現的數據庫事務處理可以提供最好的性能，因為它只需要一次數據庫往返操作。雖然它提供了很好的性能和靈活性，但用戶還需要在 Transact-SQL 中進行編碼，而這并不像在 .NET 中那樣簡單。

使用 ADO.NET 事務處理對象的手動事務處理很容易進行編碼，而且用戶可以使用顯式的指令開始和結束事務處理，因而在控制事務處理的范圍時具有很大的靈活性。與這種方便和靈活性相對應的是，ADO.NET 手動事務處理需要進行很多次往返操作，至少等于事務處理中要執行的操作數加上開始和結束事務處理所需要的往返操作次數。

由于和 DTC 的交互以及和 COM 的相互操作，自動事務處理模型還會產生一些額外開銷。而與 DTC 相關的成本可以分攤到整個事務處理過程中，如測試中所示。使用此模型的優點是大大簡化了應用程序的設計并減少了編碼需求。如果事務處理跨越多個能夠識別事務處理的資源管理器（可能包括 SQL Server 數據庫和 MSMQ 消息隊列），那么只能選擇自動事務處理。