压力测试跑完以后，工具里往往会生成好多张图表，如果只是顺着顺序一张一张往下翻，通常很难一下子抓到真正有用的信息，所以要弄清楚LoadRunner Analysis里的图表到底该怎么看，又该怎么从这些图表里面判断出系统的瓶颈到底卡在了哪里，比较合理的思路是先关注用户负载和各个事务的响应时间，接着再把吞吐量、请求数量、错误数量以及服务器那边的资源数据结合起来一起分析，光是看到响应时间变长了，只能说明系统处理变慢了，并不能直接断定问题就是出在数据库、网络或者应用程序本身。

　　一、LoadRunner Analysis图表怎么看

　　在LoadRunner Analysis工具里查看结果的时候，不适合一口气同时打开太多的图，可以先用几张最核心的图，把整个压测过程大致划分成加压阶段、稳定运行阶段和减压阶段，再针对那些表现异常的时间段做进一步的细查，这样更有条理。

　　1、先看运行用户数

　　进到Analysis之后，通过【Graph】→【Add New Graph】这个路径，把Running Vusers这张图加进来，它主要用来确认在不同时间点上到底有多少个虚拟用户在同时执行操作，后面再看响应时间和吞吐量的时候，都得拿这个用户数量的变化来当作基本的参照，如果离开了用户负载的背景，单独看别的指标就很容易判断偏掉。

　　2、再看事务响应时间

　　接着可以把Average Transaction Response Time这张图也添加上，从这张图里能观察到登录、查询、提交还有保存这些关键业务事务的耗时是怎么起伏的，通常还可以把它跟Running Vusers关联起来放在一起看，这样当虚拟用户数逐渐往上加的时候，就能比较清楚地看出事务的响应时间是不是也跟着同步拉长了，从而判断系统的承受能力。

　　3、查看请求量和吞吐量

　　再继续把Hits per Second和Throughput这两张图加进去，Hits per Second表示每秒钟发到Web服务器那一端的HTTP请求个数，适合用来衡量请求压力的大小，而Throughput则反映了单位时间内真正传输过去的数据量有多少；这两张图要放在一起比对着看，如果请求的数量还在增长，但是吞吐量却开始走平甚至往下掉，往往就说明系统内部可能已经出现了排队、阻塞，或者响应速度跟不上请求的速度了。

　　4、补充事务和错误图

　　另外还需要把Transactions per Second和Errors per Second也补充进来，每秒钟通过的事务数能够反映出系统实际完成业务动作的真实处理能力，而错误图则专门用来帮助发现超时、连接失败还有服务端返回异常这类问题，如果只是简单地看平均响应时间，就很容易漏掉一部分请求其实已经失败掉的情况，导致对系统状态的判断过于乐观。

　　二、LoadRunner Analysis瓶颈结论应该怎么判断

　　在动手写瓶颈结论的时候，不能只简单地写一句“响应时间过长”就结束了，而是需要把异常的现象、它发生的时间点、负载的变化情况，还有对应时刻服务器那边的资源状态都串到一条线上，才能形成一条可以继续往下排查的明确线索。

　　1、响应时间升高但请求量不再增加

　　如果在压测过程中，虚拟用户的数量还在持续地往上加，事务的响应时间也跟着明显上升，但是Hits per Second和Throughput这两条曲线却开始横盘、甚至往下降，那就说明系统的处理能力很可能已经逼近了当前配置下的上限；这个时候，应该先把出现异常的时间段记下来，然后赶紧去查看服务器端的CPU、内存、磁盘和数据库连接这些指标的状态，看看它们是不是也已经到了瓶颈。

　　2、响应时间稳定但错误量上升

　　还有一种情况是，事务的响应时间看起来好像并没有太大的变化，可Errors per Second的曲线却在不停地往上走，这时候就要马上去查看错误的具体内容是什么，因为很可能有一部分请求还没有等到超时，就在半路上被直接拒绝掉了，比如连接池被耗尽了、服务端触发了限流机制，或者接口返回了异常的响应码，面对这种情况，绝对不能把测试结论简单地写成“性能正常”。

　　3、吞吐量升高但事务量没有同步增加

　　如果发现吞吐量明明在往上走，可是每秒钟真正完成的事务数量却没有跟着同步增长，那就要怀疑是不是静态资源、大体积的附件或者过大的响应报文，占去了大量的传输带宽，而真正的业务事务压根就没有获得相应的提升；这时候得回到测试脚本里面去检查事务的边界是不是划得准确，也要去看一看有没有发生重复下载、接口频繁轮询或者发出了很多无关的请求这类情况。

　　4、资源使用率异常时再定位组件

　　LoadRunner本身也支持配合系统资源监控，来观察服务器那一边的表现，帮助把瓶颈定位到更具体的组件上去；如果发现CPU的使用率长期维持在高位，就可以继续往下排查那些计算密集型的接口，如果内存的占用量一直往上涨，就得去关注是不是缓存配置得过大或者存在内存泄漏，如果磁盘的等待时间明显变长了，就要查一查日志写入和数据库读写的压力，而如果网络已经接近了带宽的极限，那就要看看是不是大文件和响应体积造成的问题。

　　三、LoadRunner Analysis瓶颈结论怎么复核

　　光凭图表上的一次异常并不能马上拍板定论，测试产生的结果要能够被稳定地复现出来，而且还要和脚本的设置、监控系统拿到的数据以及当初定下的业务目标，这三者之间能够相互对得上。

　　1、把异常时间段单独放大

　　可以在图表里面把时间窗口缩小，专门只看问题出现前后那几分钟的细节，把虚拟用户数量、事务响应时间、请求数量和错误数量这几条曲线都放在同一条时间轴上，这样往往就比较容易看出到底是最先起变化，从而帮我们找到触发点。

　　2、使用图表关联查看

　　Analysis这个工具允许把两张图关联起来一起查看，比如把Running Vusers和Average Transaction Response Time上下对齐，也可以再进一步把Throughput和Errors per Second放到一起比较，这样一来，就能避免只凭单独一张图就贸然下结论，判断起来会稳得多。

　　3、结合SLA检查结论

　　LoadRunner相关的平台里可以设定SLA，并且结合运行的用户数、吞吐量、每秒钟的请求数和事务数这些负载条件，来判断本次测试结果到底有没有达到合格线；在写项目报告的时候，一定要把测试施加的具体负载、响应时间的目标值、报错的具体情形还有异常发生的时间点都交代清楚，而不只是简单地把几张截图贴上去，这样后面的同事接手时才不会一头雾水。

　　总结

　　用LoadRunner Analysis分析结果的时候，看图可以按照这样的顺序入手：先看Running Vusers和Average Transaction Response Time，再接着把Hits per Second、Throughput、Transactions per Second和Errors per Second这些图补全；到了判断瓶颈的阶段，要把注意力集中在同一时间段内不同曲线之间的联动变化上，然后再配合服务器资源监控继续往深处追；图表本身最多只能帮助我们把问题出在哪个环节指出来，真正要敲定瓶颈的结论，还是得依靠日志、监控系统提供的信息，再加上能重复验证的测试，才能把结论坐实。