性能比较：事务处理控件

领测软件测试网

在 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 和数据封送相关的成本也因大型事务处理的分摊而降低了。　总结 每个事务处理模型在应用程序性能和代码可维护性方面都各有侧重，因此它们适用于不同的方案。 运行存储过程中实现的数据库事务处理可以提供最好的性能，因为它只需要一次数据库往返操作。虽然它提供了很好的性能和灵活性，但用户还需要在 Transact-SQL 中进行编码，而这并不像在 .NET 中那样简单。 使用 ADO.NET 事务处理对象的手动事务处理很容易进行编码，而且用户可以使用显式的指令开始和结束事务处理，因而在控制事务处理的范围时具有很大的灵活性。与这种方便和灵活性相对应的是，ADO.NET 手动事务处理需要进行很多次往返操作，至少等于事务处理中要执行的操作数加上开始和结束事务处理所需要的往返操作次数。 由于和 DTC 的交互以及和 COM 的相互操作，自动事务处理模型还会产生一些额外开销。而与 DTC 相关的成本可以分摊到整个事务处理过程中，如测试中所示。使用此模型的优点是大大简化了应用程序的设计并减少了编码需求。如果事务处理跨越多个能够识别事务处理的资源管理器（可能包括 SQL Server 数据库和 MSMQ 消息队列），那么只能选择自动事务处理。
//

文章来源于领测软件测试网 https://www.ltesting.net/