性能比较： 事务处理控件（构建分布式应用程序）

性能比较： 事务处理控件（构建分布式应用程序）

发布日期： 4/1/2004 | 更新日期： 4/1/2004

使用 Microsoft .NET 构建分布式应用程序

Priya Dhawan

Microsoft Developer Network

2002 年 2 月

摘要： 本文通过比较事务处理模型（包括使用 Microsoft SQL Server 2000 数据库的通用应用程序方案中的数据库事务处理、Microsoft ADO.NET 手动事务处理和 ADO.NET 自动事务处理），重点介绍影响性能、可伸缩性和可维护性的事务处理控件的性能部分。（11 页打印页）



本页内容

	简介
	体系结构选项
	测试方案
	测试工具和策略
	计算机配置
	性能测试结果
	小结

简介

事务处理控件的体系结构选择影响到性能、可伸缩性和可维护性。 本文通过比较各种事务模型（包括使用 Microsoft SQL Server? 2000 数据库的通用应用程序方案中的数据库事务处理、Microsoft_ ADO.NET 手动事务处理和 ADO.NET 自动事务处理）的相关性能，重点介绍这些选择的性能部分。

有关显示此处所比较技术方面的代码示例，请参阅 Transaction Control中的相关文章。



返回页首

体系结构选项

事务处理控件模型包括数据库事务处理、手动事务处理和自动事务处理。虽然这些模型完成的任务相同，即维护某个事务处理范围内资源之间的一致性，但它们又各有优缺点，因此用途也各不相同。

数据库事务处理

数据库事务处理是在 Transact-SQL 中实现的，Transact-SQL 将所需的操作包装在 BEGIN TRANSACTION 和 COMMIT/ROLLBACK TRANSACTION 语句中。

手动事务处理

使用一组 ADO.NET 对象手动控制事务处理范围，并使用明确的指令开始和结束事务处理。

自动事务处理

在 Microsoft Windows_ 2000 组件服务 (COM+) 中注册 .NET 类，以便参与事务处理。 该类具有声明性属性的标记，指定该类参与事务处理的方式。



返回页首

测试方案

为了比较事务处理模型，我们使用了一个方法，在数据库的相应表中插入定单标题及其详细信息。 如果任何插入操作失败，我们将事务处理恢复到原始状态。如果所有插入操作成功，则提交事务处理。

为了使测试尽可能符合实际情况，加载的数据库中包含了 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 Application Center Test (ACT)。它旨在对 Web 服务器进行强度测试，并分析 Web 应用程序（包括 ASPX 页及其使用的组件）的性能和可伸缩性问题。有关如何创建和运行测试的详细信息，请参阅ACT 文档。通过打开到服务器的多个连接并迅速发送 HTTP 请求，Application Center Test 可以模拟一大组用户。它还允许我们建立实际的测试方案，我们可以在方案中使用一组随机参数值调用同一个方法。此功能很重要，这样用户就不必使用相同的参数值反复调用同一个方法。另一个有用的功能是，应用程序中心测试可以记录测试结果，从而提供有关 Web 应用程序性能的最重要的信息。

根据业务需求不同，应用程序可以在不同的事务处理隔离级别上运行。 隔离是指一个事务处理必须和其他事务处理分离的程度。隔离级别越高，越能保证数据的一致性，但可能会严重影响应用程序的伸缩能力。 降低隔离级别可以增强应用程序的可伸缩性，但却不能保证数据的准确性。Microsoft SQL Server 2000 支持四种隔离级别： READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIAZABLE。 默认情况下，它在 READ COMMITTED 隔离级别下运行。 有关详细信息，请参阅 Microsoft SQL Server 2000 文档 。 Windows 2000 上运行的 COM+（1.0 版）只支持 SERIALIAZABLE 隔离，即最高程度的隔离。 这样高的数据保护级别大大影响了性能。（注意：与 Microsoft Windows Server 2003 一同发行的 COM+ 1.5 允许对事务处理组件的隔离级别进行配置。） 为了对事务处理模型进行客观的比较，我们在 SERIALIAZABLE 隔离级别上运行事务处理。



返回页首

计算机配置

下表提供了用于执行测试的测试台配置的简单摘要。

表 1. 客户机配置

1	Dell Precision WorkStation 530 MT 1694 MHz	1	512 MB	16.9 GB	• Windows XP • 应用程序中心测试

表 2. Web 服务器配置

1	Compaq Proliant 400 MHz	4	640 MB	50 GB	• Windows 2000 Advance Server SP 2 • NET 框架发行版本

表 3. 数据库服务器配置

1	American Megatrends Atlantis 800 MHz	2	1 GB	28 GB	• Windows 2000 Advance Server SP 2 • SQL Server Enterprise Edition SP 2

返回页首

性能测试结果

吞吐量和滞后时间是关键的性能指标。对于给定数量的返回数据，吞吐量是指单位时间（通常是 1 秒）内处理的客户端请求数量。因为从可用性角度来看，吞吐量在某一响应时间达到峰值是不能接受的，因此我们跟踪了滞后时间，利用由 Application Center Test 为运行的每个测试生成的报告，将其作为响应时间进行测定，并在响应时间超过 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 中的库程序包可以使程序集在调用应用程序进程（本例中是 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 表分别关联了 DataAdapters。 在 DataAdapters 上，为 InsertCommand 指定了存储过程。 首先调用与 Order 表对应的 DataAdapter 的 “更新” 方法，它返回新插入定单的 OrderId。 然后调用与 OrderDetails 表对应的 DataAdapter 的 “更新” 方法。 因为 “更新” 方法不是以批处理方式向数据库发送更改，因此这一技术使用了多次数据库往返操作，以完成这些插入。

可以参阅性能比较： 数据访问技术一文，该文比较了各种数据访问技术（包括 OPENXML 和多个 DataAdapters 方法）。

该测试首先运行 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 提供的性能好，这是由于在 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 和数据封送处理相关的成本也因大型事务处理的分摊而降低了。



返回页首

小结

每个事务处理模型在应用程序性能和代码可维护性方面都各有侧重， 因此它们适用于不同的方案。

运行存储过程中实现的数据库事务处理可以提供最好的性能，因为它只需要一次数据库往返操作。 尽管它提供了很好的性能和灵活性，但用户还需要在 Transact-SQL 中进行编码，而这并不像在 .NET 中那样简单。

使用 ADO.NET 事务处理对象的手动事务处理很容易进行编码，而且用户可以使用显式的指令开始和结束事务处理，因而在控制事务处理的范围时具有很大的灵活性。与这种方便和灵活性相对应的是，ADO.NET 手动事务处理需要进行很多次往返操作，至少等于事务处理中要执行的操作数加上开始和结束事务处理所需要的往返操作次数。

由于和 DTC 的交互以及和 COM 的相互操作，自动事务处理模型还会产生一些额外开销。 而与 DTC 相关的成本可以分摊到整个事务处理过程中，如测试中所示。 使用此模型的优点是大大简化了应用程序的设计并减少了编码需求。 如果事务处理跨越多个能够识别事务处理的资源管理器（可能包括 SQL Server 数据库和 MSMQ 消息队列等），那么只能选择自动事务处理。

转到原英文页面