根据业务的运行情况入手，以突出问题为主线，定位瓶颈，进行调优；执行后再验证性能，未达到性能需求继续找突出问题，分步调优。本分析以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较长，进而分析该项的time to first buffer情况。
First buffer time：
细分为服务端时间、网络时间。
现象:
网络时间明显很大。
分析：
此文件的网络时间较长，可推论出网络方面的问题，需要进一步查看网络指标确定。