VS2010分布式和异构应用程序的负载测试(下)
wangyjbk 2010-04-27
对每个失败的Web请求显示PurePath
在VS2010负载测试运行设置（Run Configuration）中，你可以指定把详细的反应结果存储在一个SQL数据库中。这使得你在负载测试完成之后，可以查找单个失败的事务处理，包括实际的HTTP流量以及所有相关的时间。在我的测试中就有另外一个较慢的事务处理，名字叫BuyDirect。我通过VS2010 Load Testing Report打开了那些失败的事务处理，并对那些速度慢的请求进行了分析：
负载测试的问题请求，连接到dynaTrace PurePath
结果视图（result view）告诉我，这个请求用了1.988秒。dynaTrace VS2010插件在Results Viewer中添加了一个新的标签，点击一个PurePath连接就可以打开捕获的PurePath来查看那个特别慢的请求。点击这个连接会在dynaTrace Client中打开PurePath：
从Visual Studio打开的长时间运行的异构事务处理
我们能很容易的发现在这个事务处理中时间都花在了哪里---都花在了从第二个JVM (GoSpaceBackend)到承载Web Service (DotNetPayFrontend)的CLR的网络服务调用上。其中一个问题似乎也跟调用网络服务时发生的异常情况有关。这些异常情况不能构成我们自己的日志架构，因为它们是由Axis内部处理的，但是它们会由配置问题引起（我们可以去查看完整的异常堆栈跟踪来查明事实）。进一步往下点击，我可以看到这个处理的Sequence Diagram程序流程图。这个流程图更好的描述了4个不同服务器之间的交互活动：
dynaTrace程序流程图，显示了在单个事务处理中服务器之间的交互活动
程序流程图的内容比截图中内容丰富得多，但我猜你已经知道，我们已发现了一个服务器之间交互率非常高的事务处理。
dynaTrace VS2010 Plugin让我在几秒钟之内就找到了分布式异构事务处理中存在着问题的方法，比单独依靠负载测试报告来分析这个问题节省了大量的时间。
跟开发人员分享测试结果，并在源代码中找到问题的出处
现在，我们已经拥有了所有重要的信息，并且已经发现了几个开发人员应该仔细调查的热点问题。我只是简单的把捕获的数据导出到一个dynaTrace Session文件中，并把它附在一个我指派给开发人员的JIRA文档上面（或其他bug追踪工具），而不是让开发人员来访问我的测试环境。我也可以导出所有捕获的数据，或者更明确的说，只导出那些被识别出来的有问题的PurePaths。
开发部门拿到dynaTrace Session文件之后，会将其导入到自己的本地dynaTrace Client中，并分析我们在测试环境中已经分析过的那些相同粒度(same granular)的数据。安装dynaTrace Visual Studio 2010 Plugin之后，开发人员可以从PurePath中或者dynaTrace Client的Methods Dashlet中开始查找Visual Studio中的单个方法：
查找问题方法的源代码
Visual Studio的dynaTrace Plugin插件会对所选择的方法进行搜索、打开源代码文件，并把光标放在那个方法上，但前提是你必须保持你的解决方案文件是打开的：
在Visual Studio 2010编辑器中显示出问题方法的源代码
你可以很容易把这些数据跟需要研究它们的人进行分享。在短短几秒钟内，开发人员就可以在Visual Studio 2010中找到那行有问题的、影响性能的源代码。开发人员还可以查看所有的背景资料，它们可以显示出为什么同一个事务处理的单个执行比其他的要快，因为PurePath包含诸如方法参数、HTTP参数、带有Bind变量的SQL语句、Exception Stack Traces等信息，所有这些信息都是开发人员所喜欢的。
通过测试运行来识别回归（Regressions）
当针对不同的build版本连续运行负载测试时，我们期望其性能会越来越好。但是，如果情况不是这样呢？上一个build版本到目前的版本都有哪些改变？哪些模块的表现不如上一个版本中的好？我们访问数据库的方式变了吗？自定义代码的算法是否用时太多，或者引入到这个build版本中新的第三方库是否让所有操作的速度都变慢了？
Automatic Session Analysis 插件还能分析在两个负载测试会话之间传递的数据，并产生一个报告，显示出这两个会话的不同之处。下面的屏幕截图显示了一个负载测试的回归分析结果：
通过比较两个负载测试会话得到的回归分析
上图显示了最新版本（左上角）以及上一个build版本（右上角）中实际执行了哪些处理。在窗口的中间，我们可以看到每个会话中哪些层/模块消耗了系统性能，还有一个并列的对比（中央），那些时间条告诉我们哪些模块执行得更快或者更慢。我们似乎在大多数模块中都存在着某些严重的性能降低。在底部，我们还看到一个已执行的数据库语句与方法的比较。就像我在上一节中所说的那样，我们可以通过这个报告掌握更多的细节，进而对更多的细节进行分析。
总结
Visual Studio 2010是针对.NET或者Java网络应用程序执行负载测试的一个好工具。在这个版本中，Load Testing Report（负载测试报告）已经得到了改进，你可以对应用程序的性能有一个更好的理解。对于多层或者异构应用程序来说，正如我以上使用的那种，现在通过一个像dynaTrace这样的应用程序管理方案就能很轻松的获得比标准负载测试报告更多的信息。把负载测试方案以及APM方案结合起来使用，不仅能帮助你发现性能问题，还可以让你更快的找出问题所在，从而减少了测试周期以及测试阶段所花的时间。
