译者：原始文章有点性能测试工具软文的感觉，毕竟文章来源于某工具官方博客。高手请略过。
对于我这种新手，此文还是给我带来一些惊喜，从上到下地，从表象到根源地，定位他们遇到性能问题-响应时间过长-的根本原因，有具体的步骤，思考和判断依据，这就是一个比较不错性能测试分析实例。可以更清楚看到性能测试如何分析定位，可以学习其思路。故分享之。
原文连接:http://apmblog.compuware.com/2013/06/04/how-to-accurately-identify-impact-of-system-issues-on-end-user-response-time/
以下为正文
我们希望检测下我们社区网站的负载能力，所以我们开发团队进行了一个任务，验证生产环境的系统是否能在现有的硬件基础上处理10倍于目前的负载。为了将网站在高负载下可能的崩溃影响降到最低，我们决定在周日下午进行第一轮测试。在运行测试之前，我们给运维团队提了一个醒：他们可能在这次两小时的期间观察到明显的负载变化，从而可能影响到运行在同一环境下的其他应用程序。
在测试过程中，运维团队和开发团队一起监控实时性能数据，当达到一定的负载水平后，我们看到最终用户的响应时间和耗尽资源。在本次测试中非常有趣的是，开发团队和运维团队都看着相同的数据，但是却从不同的角度去审视这些结果。然而，他们都是依赖于最近才公布的Compuware的PureStack技术，这是——整合dynaTrace和PurePath——的第一个解决方案，显示出在高负载下生产环境的硬件是如何影响到关键业务应用程序的性能。
上下文为运维团队和开发团队的数据之间架起桥梁：这张图片显示"横向"事务以及"纵向"层面的热点区域(BridgingtheGapbetweenOpsandAppsDatabyaddingContext:OnepicturethatshowstheHotspotsof"Horizontal"Transactionaswellasthe"Vertical"Stack.)。
在我们的场景中表现不佳的根本原因-一个运行着Web和应用程序服务的主服务器的CPU被耗尽-从而导致达不到我们的负载目标。事实证明，这个问题是跟硬件设备和应用程序都有关系(ThisturnedouttobebothanITprovisioningandanapplicationproblem)。让我解释一下团队的步骤以及他们是如何得出他们的行动项列表，以便改善目前的系统性能，以便在第二轮测试中得到更好的结果。
第1步：监控和识别硬件健康状况
运维团队希望能够看着他们的服务器列表，而所有关键指标（CPU，内存，网络，磁盘等）都能很快地呈现出绿色状态(OperationsTeamslikehavingtheabilitytolookattheirlistofserversandquicklyseethatallcriticalindicators(CPU,Memory,Network,Disk,etc)aregreen)。但是，当我们的负载测试达到了顶峰时，他们看向服务器的状态时，显示出来却是，他们有2台机器正出现了异常：
我们的社区网站核心服务器出现CPU相关的问题，并影响到另一运行在这台服务器上的应用程序。
步骤2：哪些运行中的应用程序被真正影响到了？
单击受影响的程序选项卡，它会显示受影响的机器上所有运行的应用程序，以及目前受影响的应用程序：
增加的负载不仅影响到社区网站，而且也影响到我们支持网站
这次负载测试已经让我们明白：如果我们希望未来的社区网站能够承担更高的负载，那我们可能需要移动支持网站到其他的机器，以避免不必要的影响。
