VS2010分布式和异构应用程序的负载测试（上）

但是，在我们探索通过扩展Visual Studio能做什么之前，让我们看看没扩展时我们能得到哪些东西：

Visual Studio 2010的标准负载测试报告

Visual Studio 2010运行负载测试是为了收集各种各样的信息。这些信息包括执行要求的反应时间、被测应用程序基础设施（比如CPU，内存，I/O, …）的性能计数器，以及你的负载测试基础设施（负载控制器及代理）的健康程度。我运行了一个4层（2个JVM, 2个 CLR）的网络应用程序。4个层通过SOAP Web Services (Axis->ASMX)进行交流。这个前端网页应用程序是用Java Servlets实现的，在15分钟的测试中负载不断增加。测试分为多个不同的事务处理，比如：Home Page、Search、Login、BuyDirect等…---当运行测试的时候，我也同时监视了所有相关应用程序服务器以及负载测试基础设施的性能计数器。Visual Studio 2010 允许我通过可配置的曲线图来监视负载测试的当前状态，具体曲线图如下所示：

Visual Studio负载测试曲线图

该图显示，随着用户负载的增加，我的事务（不是全部）处理的反应时间也在增加。图中还显示出应用程序服务器上的CPU使用率出现了问题（同时有差不多20个用户时，CPU的使用率就会超过80%）。在负载测试的最后，会有一个总结报告，描述了对于这个应用程序执行了哪些负载---发生了哪些错误以及哪些页反应最慢：

负载测试总结报告

把报告切换到表格视图，会有一个单个结果特征的详细分类，比如Transactions、Pages、 Errors（事务处理，页，错误，）等等：

Visual Studio负载测试汇总表格

从表格试图中我们可以得到以下结论：

 553页的请求超过了我的每页200ms规则

 553页是属于menu.do, netpay.do 以及 userlogin.do（当你查看单个错误请求的时候，你就可以看到这个）

 该LastMinute事务处理是目前最慢的，平均反应时间1.41秒，最大反应时间为5.64秒。

我们不知道的是这些事务处理为什么这么慢：性能计数器表明CPU是一个潜在的问题，但是它没有告诉我们，是什么造成了CPU负载增大，这个问题是否能被解决或者说我们是否已经达到了系统性能的上限。

dynaTrace捕获的Visual Studio 2010负载测试执行情况报告

dynaTrace用户可以从dynaTrace Community Portal（dynaTrace社区门户）下载这个Visual Studio 2010插件。这个程序包里含有一个Visual Studio外接程序以及一个Visual Studio测试插件库，扩展了其网络测试以及负载测试的能力。我们也提供Automatic Session Analysis（自动会话分析插件），能够帮忙分析从较长时间的负载测试中捕获的数据。

在我的4层应用程序中进行负载测试时，我使用的是dynaTrace Test Center Edition（测试中心版）。这个Visual Studio 2010插件确保了dynaTrace能够自动捕获所有dynaTrace会话中的服务器端事务处理（PurePath的）。它还确保那些跟Web Test脚本中名字相同的事务处理都会传递到dynaTrace。

在运行负载测试过程中，我创建的Load Testing Performance Dashboard（负载测试性能仪表板）使得我可以观察传入的请求以及每个JVM和CLR中的内存使用情况。我能看到我的应用程序中是哪些层次对系统的性能产生了影响--- ADO.NET, ASP.NET, SharePoint, Servlets, JDBC, Web Services, RMI, .NET Remoting等等层---dynaTrace会自动监测这些层，而且还帮助我理解应用程序中实际上是哪些部件/层次消耗了大部分的执行时间以及逐渐增加的负载对这些部件的影响分别是怎样的。除此以外，我还能观察到执行的SQL语句数量（不管是通过Java还是.NET），以及发生的异常情况的数量：

dynaTrace负载测试性能仪表板

仪表板左上角的图表中显示的是单个事务处理的反应时间，其下方的图表是累积的事务处理数量。这些是进入的请求数量，从中我们很容易获悉VS2010是怎样在测试中增加负载的。

仪表板右上角的图表是两个JVM的内存使用情况，其下方的图表是两个CLR的内存使用情况（在我的第二个JVM中似乎存在着一个内存泄漏，而且还有一个非常“安静的”CLR）。

仪表板左下角的图表显示的是我的应用程序随着逐渐负载的增加有什么变化。我能看到我的应用程序表现一直都还不错，直到一个特定的用户负载得出现。但是，Web Service Layer（网络服务层）（黑灰色）的性能表现开始比其他所有有关的应用层差很多。

仪表板右下角的数据库语句数量以及异常情况数量告诉我，这些计数器随着负载的增加而线性的增长。但是，似乎我们有相当多的数据库查询（高达350/second），还有非常多的异常情况值得调查。

在负载测试完成之后，我得到的第一个报告显示出速度最慢的网络事务处理，它们按照Visual Studio中的名字进行归类：

dynaTrace每个网络处理的性能报告

从上图中，我可以看到LastMinute处理的确是最慢的处理，反应时间5.6秒是最大的。从这个报告中，我们能够将高级事务处理分解成应用层、数据库调用以及方法调用，从而进行细致的分析，这是该报告的最大优点所在。根据这个分类我们能够立即看出对于Last Minute处理来说，Java Web Service是最高的性能消耗者。我们也能看到448个对此事务处理的请求包含有几千个数据库查询，我们还能看到是哪些Java以及.NET方法占据了系统的执行时间。点击Slowest Page会打开PurePath Dashlet，它显示出每个已执行的事务处理。如果按持续时间进行排列，还可以显示出各个处理的执行时间有着巨大的差异。PurePath Hot Spot视图让人很简单的就能揪出在最慢的事务处理中最消耗性能的方法：

 运行最慢的事务处理中，不同的PurePath之间差别很大

有了PurePath Comparison功能，我可以进一步找出两个执行时间差别很大的事务处理有什么不同：