領測軟件測試網
在 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 中的庫程序包可以使程序集在調用應用程序進程(本例中是 aspnet_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 Access 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 和數據封送相關的成本也因大型事務處理的分攤而降低了!】偨Y 每個事務處理模型在應用程序性能和代碼可維護性方面都各有側重,因此它們適用于不同的方案。 運行存儲過程中實現的數據庫事務處理可以提供最好的性能,因為它只需要一次數據庫往返操作。雖然它提供了很好的性能和靈活性,但用戶還需要在 Transact-SQL 中進行編碼,而這并不像在 .NET 中那樣簡單。 使用 ADO.NET 事務處理對象的手動事務處理很容易進行編碼,而且用戶可以使用顯式的指令開始和結束事務處理,因而在控制事務處理的范圍時具有很大的靈活性。與這種方便和靈活性相對應的是,ADO.NET 手動事務處理需要進行很多次往返操作,至少等于事務處理中要執行的操作數加上開始和結束事務處理所需要的往返操作次數。 由于和 DTC 的交互以及和 COM 的相互操作,自動事務處理模型還會產生一些額外開銷。而與 DTC 相關的成本可以分攤到整個事務處理過程中,如測試中所示。使用此模型的優點是大大簡化了應用程序的設計并減少了編碼
需求。如果事務處理跨越多個能夠識別事務處理的資源管理器(可能包括 SQL Server 數據庫和 MSMQ 消息隊列),那么只能選擇自動事務處理。
//
文章來源于領測軟件測試網 http://www.kjueaiud.com/