根据业务的运行情况入手，以突出问题为主线，定位瓶颈，进行调优；执行后再验证性能，未达到性能需求继续找突出问题，分步调优。本分析以error为主线，找error的产生原因，定位到了瓶颈，针对瓶颈做调优。性能分析包含系统架构的各方面、各环节。

⑴.Analysis Summary

场景的大概情况。

现象：

     Transaction Summary 部分显示：

     Average表明事务的平均响应时间。响应最慢的事务：check_itinerary；

     Fail表示事务失败的个数。失败较多的事务：check_itinerary；

     Std. Deviation表明事务的波动情况、稳定性。波动较大的事务：check_itinerary；

     90 Percent表明90%的事务的响应时间，波动大的事务查看90%的响应时间较准确。90%响应时间较大的事务：check_itinerary；

分析：

     从响应时间、波动性、失败情况可以看出问题最突出是check_itinerary事务，进一步分析该事务。

⑵.Running Vusers

running vuser为场景运行时，正在运行的vuser情况。由于性能的问题由并发增大引起，所以，看其他指标需要结合running vuser情况。

现象：

       起始为10个vuser，以10的阶梯递增，在1：36秒维持了3分钟，而后以1个阶梯减少；

分析：

     需结合其他指标图表。

⑶.Errors per Second (by Description)

     每秒的错误数信息。可以查看随着运行时间，不同错误的发生曲线。

现象：

     在高并发时，前三个为突出的问题；Error 27728、27727出现在高并发阶段；Error 17999 运行1分开始小幅波动，但具体什么错误不知道。

     Error 27796：connection refused；

     Error 26377：未找到关联；

     Error 26374：响应为空，可能导致了未找到关联的错误；

     Error 17999：message box处发生的错误；

     Error 27728：step download timeout下载non-resource元素时，下载超时；

     Error 27727：step download timeout下载resource元素时，下载超时；

     前3个问题发生较多，中间有下降、上升的大幅波动，最后下降，呈M状，3个问题的趋势一致。

分析：

Error 27796：说明了，和服务端连接有问题；需要确定连接数是不是满了，排查连接各环节的连接设置，看Connections图；

Error 26377、26374：说明了，服务端未响应；进而需要看throughput、Average Transaction Response Time、transactions per second此类服务端性能的指标；

Error 17999：暂不清楚；

Error 27728 、27727：在高并发时才出现的下载超时的问题，应考虑服务端的处理能力；（如果场景开始就有下载超时，就需要检查runtime setting-internet protocol中对超时时间的设置是不是太小了）

结合vuser图，错误集中时段是并发数高于55个vuser 时间段，高并发导致了大量的error。系统目前性能情况，最大允许并发为55。

Error：连接拒绝

I．1  Hits per Second-Connections

连接数显示了场景运行时，打开的http连接数。

     根据上一步的推论，查看随着vuser的增加，请求的增加，连接数是否达到了最大，因此导致了服务端拒绝访问的问题。如果是这样的情况则需要调整web服务端的最大连接数。

     正常情况下，连接数的趋势应该随着vuser增加，请求增加，是逐步增加。但是此图曲线有中间的下降，需要结合点击率来较为准确的查看请求情况。

现象：

     点击率开始为增加趋势，中间有降、升，而后波动，最后下降，基本呈M状。

分析：

     考虑到连接统计的延迟，连接数基本符合点击率的波动情况，但是后面仍然保持在较高的连接数；

     推论一、是否是因为连接未及时关闭，致使连接数满了，继而导致了服务端拒绝连接的问题；进而需要查看每秒的连接打开和关闭情况。

     推论二、服务端、客户端之间的连接数设置的过小，导致连接数满了。

I．2  Connections per Second

显示了在运行时，打开和关闭的http连接情况。如果连接关闭的曲线和连接打开的曲线差得多，表明连接未被及时关闭，连接被占用，会导致服务端连接的满了，拒绝客户端的访问的错误。

现象：

     曲线基本一致。

分析：

     不是因为连接关闭不及时导致的连接数满，服务端拒绝访问的问题。所以根据上一步的推论二基本确定连接数设置问题，需要进一步查看web server、服务端操作系统连接数设置、客户端操作系统连接设置、lr运行的设置等相关的连接数情况。

Error:服务端响应不过来

II. 1 Throughput

显示场景运行时，每秒从服务端获得的数据量，可以判断服务器的处理能力。

现象：

     吞吐量开始递增，而后在高并发阶段趋势较平稳，最后下降。

分析：

     服务端处理能力较为稳定，没有发现问题。

II. 2 Hits per Second - Average Transaction Response Time

Average Transaction Response Time显示场景运行时，事务执行所用的时间。事务的响应时间和请求数结合来看，查看check_itinerary事务响应时间。

现象：

     两个曲线在中间大幅下降后，后面波动的趋势大致相符。

分析：

     响应时间的降低是因为点击率减少，服务端接收到的实际请求减少，压力较小，响应快了。未分析出其他问题。

II. 3 Transaction per Second

     显示了事务的成功、失败、停止的数量，通过此项可以确定系统在时间点的事务负载情况。和平均事务响应时间对比，可分析事务数对执行时间的影响。

现象：

     check_itinerary成功的事务较波动，数值较小；check_itinerary失败的事务集中时间为并发高峰时段。

分析：

     TPS数值太小，说明了的服务端处理事务能力较弱，继而需要查看system resource图。

II. 4 System Resource

      处理器的指标

现象：

     Processor_total大部分在90%以上，表明cpu配置较低；

     Interrupted/sec中断并发高时较多，但低于60%；

     Process_xiwin32较为平稳；推测为xiwin32进程（web server）；

     Processor queue length cpu的平均负载很大；

分析：

     系统cpu瓶颈较明显，又考虑process_xiwin32占用cpu不算多。推测是由于系统服务端其他进程占中了大部分cpu。优化服务端的进程情况，使web服务更有效的占用cpu；或更换高配的cpu；或改为linux服务器，减少其他进程的占用。

  内存的指标

现象： Private byte 随并发请求增加，内存相应增加，后面下降。

分析：未发现问题。 

  磁盘的指标

现象： 随着并发请求增加，磁盘交互响应增加，比较平稳；

分析： 未发现问题；

Transaction：check_itinerary

III.1 Web Page Diagnostics

     此图为对事务的各元素各种响应环节的细分情况。以下图为check_itinerary的事务细分情况。

现象：

     check_itinerary事务中itinerary.pl和sh_itinerary.gif的下载时间最长，请求itinerary.pl响应字节数较大，接收时间较长；sh_itinerary.gif并不大，但是first buffer time很长。

分析：

     请求itinerary.pl的业务为查询日程安排，推论是因为响应的数据量较大，导致的接收时间长。可以考虑优化该文件的代码，拆分文件，压缩输出等。

      sh_itinerary.gif文件 first buffer time较长，进而分析该项的timeto first buffer情况。

First buffer time：

细分为服务端时间、网络时间。

现象:

     网络时间明显很大。

分析：

     此文件的网络时间较长，可推论出网络方面的问题，需要进一步查看网络指标确定。

lr测试结果分析