一、结果分析思路
1.1 Analysis Summary
在Analysis Summary中主要关注Transactions图中90%的响应时间最高的事务，拿响应时间作为整个分析的突破口。
1.2 响应时间
提交请求和返回该请求的响应之间使用的时间
响应时间=后台响应时间+呈现时间
1.3 errors
分析error statistics（by Description） 和errors per Second（by Description） ，查看错误的详情（是由于什么原因产生的错误）
1.4 TPS 和吞吐率
TPS：transaction per second 服务器每秒处理的事务数
吞吐率：测试过程中每秒从服务器返回的字节数
从定义上来看，如果TPS很小，但是吞吐率比较大，说明服务器的返回的页面文件（字节数）是比较大的，此时根据页面细分图，如果存在页面问题，考虑页面压缩。
1.5 web服务器资源
Web资源分析是从服务器入手对Web服务器的性能分析
1.6 网页细分图
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
二、webtours测试结果分析
Transaction Summary
现象：事务概要图中包括每个单独事务的统计，他们的回应时间（最小、平均、最大和标准差）
图中的“90 Percent”统计指出事务在当前行90%的最大响应时间。在这个统计数值之上，可以知道90%的“check_itinerary”这件事务最大的响应时间是65.407秒
分析：根据短板效应，我们明白要分析调优应该找“最短的那块板子”
结论：所以后面分析我们要重点关注check_itinerary这个事务
Running Vusers
现象：根据图表我们可以知道，该场景模式是初始10个用户，没16秒增加10个用户，达到最大用户数70时运行3分钟在减少
分析：这和我们在加压时设置的场景基本一致
结论：虚拟用户运行正常
Error Statistics（by Description）
现象：Error 26377 No match found for the requested parameter.....是没找到关联
Error 27727 和27728是由于Step download timeout
Error 27796说链接失败
分析：针对Error26377错误找不到关联有两个原因：1、关联的位置放错了2、服务器宕机了，处理不过来。但录制脚本时，回放脚本是没有问题的且如果是脚本的错误，那么所有的事务都应该失败的，故排除第一种可能，那么就应该是服务器处理不过来导致产生这个错误。
针对Error27727和27728超时的错误，这是可以再加压之前的run-time setting -->Internet Protocol-->Preferences的options进行设置
针对Error27796链接失败的错误，先检查服务器的链接数设置是否足够大，如果设置够大的话，在检查程序是每次打开链接，是否正常关闭
结论：服务处理能力太差了，至于服务器的链接数设置的大小是否存在问题，要通过其他图标进行分析（待定）
解决方案:服务器处理能力太差可以对服务器进行升级（换CPU、内存等）、多台服务器进行负载均衡、设置参数、调链接数、添加个缓存服务器等
Average Transaction Response Time
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
在分析概要中我们知道需要对check_itnerary事务要进行分析，下图是该事务单独的平均事务响应时间
现象：前三分钟事务的平均响应时间上升，到3:30时突然下降，到快5:00左右再上升，然后再小幅度上升下降，最后为0
分析：对照前面的虚拟用户图可以知道前3分钟响应时间上升是正常的，因为在不断的添加虚拟用户，上升完后应该趋于平稳或者小幅度上升下降，但该图显示的却在急剧下降，原因应该和前面错误数图中产生的错误数有关，通过看Total Errors per Second 发现在5分钟左右错误数达到了最大值。5分钟之后响应时间在波动较正常，因为虚拟用户在慢慢退出系统
结论：在3:30出现事务平均响应时间急剧下降是不正常的，是由于这段时间产生了很多错误，导致平均响应时间下降
Transacctions per Second
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
同样在TPS表中我们还是分析check_itnerary这个事务，下图是单独将check_itnerary失败的图表打开
现象：在3:30失败数开始上升，到4:00左右失败数下降，4:20左右再突然上升到最顶端再下降
分析：事务的失败数是由于什么原因照成的呢？前面我们知道，在这段时间是产生了很多错误数的，猜测是由于错误数照成这段时间的失败的TPS过多，那么我们要回到Total Errors per Second图表去看看时间段是否符合的
结论：通过Total Errors per Second图表我们可以知道，在4：30时错误数是飙升的，和猜想一致，由于这个时间段产生了很多错误，导致TPS失败数增加
Hits per Second and Throughput
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
现象：这张图表是把hits per second和 throughput两图结合起来的结果，我们可以看到点击率和吞吐率的都是很正常的，点击率上升、吞吐率紧跟着上升，点击率下降、 吞吐率下降
分析：点击率和吞吐率的都是很正常的，点击率上升、吞吐率紧跟着上升，点击率下降、 吞吐率下降
结论：点击率、吞吐率正常
HTTP Responses per Second
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
HTTP每秒响应图统计的是HTTP响应的状态标准，最常用的标准有200（成功），302（重定向），404（未找到）和500（内部服务器问题）。增加的HTTP响应意味着服务器正在处理更多的请求，并成功发送一个HTTP的响应给用户。
现象：通过图中可知，状态码都是200，都是成功的，但在2:30 到3:30出现下降
分析：还是由于在此时间段产生了很多错误数，导致在此时间段出现了下降
结论：HTTP Responses per Second是OK的，在2:30 到3:30出现下降的原因是此时间段产生了很多错误数
Connections
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图，可以知道何时需要添加其他连接。
例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
现象：通过图表可以发现连接数是先上升、下降、上升、平稳
分析：第一阶段先上升是正常的，因为不断在添加虚拟用户，下降是有问题的，按照正常来说应该是处于平稳，在上升，可能是服务器的处理能力恢复正常了，所以又上升了，然后趋于平稳，在下降
结论：在此图中可以得知服务器的最大链接数是120，还记得Error Statistics（by Description）中分析链接不上是由于服务器处理能力太弱还是服务器链接数设置较小无法进行分辨吗？此处就可以给出答案了，链接数设置不小，是由于服务器的处理能力太弱了，导致链接不上，总之是由于服务器处理能力太弱了，导致高并发时服务器处理不过来，产生很多错误，从而链接数也相应的减少
Connections Per Second
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
现象：链接数先上升、下降、上升、下降、上升、再下降，链接关闭先不变、在上升、在下降、上升、下降
分析：可以发现链接数的打开和关闭的曲线趋势都是一致的，说明在代码中打开的链接都关闭了
结论：再次说明链接数突然下降是服务器处理能力反应不过来导致的
Page Component Breakdown(Over Time)
“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。
现象：我们对比平均响应时间，发现pl程序文件的平均响应时间消耗最长为14.863s，sh_itinerary.gif的平均时间也较大为10.345s
分析：程序pl文件响应时间较大，是不是出现了N多代码放同一文件或者代码的算法过于复杂，每次访问消耗时间过长，那么去文件中看下
结论：N多代码放同一文件，至于是否存在算法过于复杂还有待验证，请看下面的分析
Page Download Time Breakdown(Over Time)
“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。
指标说明
DNS解析时间：显示使用最近的DNS服务器将DNS名称解析为IP地址所需的时间；DNS查找度量是指示DNS解析问题或DNS服务器问题的一个很好的指示器；
Connect时间：显示与包含指定URL的Web服务器建立初始连接所需的时间；Connect度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；
First buffer时间：显示从初始HTTP请求到成功收回来自WEB服务器的第一次缓冲时为止所经过的时间；First buffer度量是很好的Web服务器延迟和网络滞后指示器；
SSL Handshaking time：显示建立SSL连接所用的时间
Receive Time：显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；
FTP验证时间：显示验证客户端所用的时间。
Client Time：显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。
Error时间：显示从发出HTTP请求到返回错误消息这期间所经过的平均时间
现象：对各指标的平均时间进行对比，发现page=itinerary的First buffer时间、Receive Time和localhost/MercuryWebTours(main URL)的First buffer的平均时间较大分别是15.022、13.679、10.173
分析：可以得出Receive Time是高的，但First buffer时间又分为服务器响应蛮和网络慢的原因，到底是服务器响应慢呢还是网络原因呢？有待验证
结论：Receive Time高是明确的，page=itinerary和localhost/MercuryWebTours(main URL)是因为服务器响应慢还是网络原因照成First buffer时间高有待验证，请看下面的分析
Time to First Buffer Breakdown(Over Time)
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。
现象：reservations.pl[Network Time]的平均响应时间为0.099、[Server Time]的平均响应时间为0.723，login.pl[Network Time]的平均响应时间为0.419、[Server Time]的平均响应时间为2.237。page=itinerary[Network Time]的平均响应时间为10.096、[Server Time]的平均响应时间为4.926。localhost/MercuryWebTours(main URL) [Network Time]的平均响应时间为0.186、[Server Time]的平均响应时间为9.987
分析：通过上面可以得出pl程序文件调用是存在两个以上的，但只有一个pl文件，说明是可以进行程序文件拆分reservations.pl and login.pl，pl文件的网络时间和服务器响应时间都不高，还记得Page Component Breakdown(Over Time)图表吗？pl程序文件的平均响应时间消耗最长为14.863s，说明是该文件的算法逻辑较复杂，以及没有对文件进行拆分。
解决方案：优化pl程序文件的算法逻辑、对文件进行拆分
Page Download Time Breakdown(Over Time)图表中是page=itinerary和localhost/MercuryWebTours(main URL)因为服务器器响应慢还是网络原因照成First buffer时间高有待验证是因为服务器响应慢还是网络原因照成First buffer时间高有待验证，看上面的数据就一目了然了，page=itinerary的First buffer时间高是由于网络原因照成的，而localhost/MercuryWebTours(main URL) 的First buffer时间高是由于服务器响原因照成的
结论：Page Component Breakdown(Over Time)中pl程序文件平均时间长是由于没有多文件进行拆分，以及该文件的运算逻辑较复杂。Page Download Time Breakdown(Over Time)图表中的page=itinerary的First buffer时间高是由于网络原因照成的，而localhost/MercuryWebTours(main URL) 的First buffer时间高是由于服务器响原因照成的
解决方案：优化pl程序文件的算法逻辑、对文件进行拆分。网络方面对宽带进行升级。服务器方面可以对服务器进行升级（换CPU、内存等）、多台服务器进行负载均衡、设置参数、调链接数、添加个缓存服务器等
Time to First Buffer Breakdown(Over Time)
“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。
现象：page=itinerary和localhost/MercuryWebTours(main URL)的平均值都较大分别是1535.727和52.585
分析：说明page=itinerary和localhost/MercuryWebTours(main URL)的组件是比较大的
结果：要和开发进行沟通，商量下page=itinerary和localhost/MercuryWebTours(main URL)可不可以进行拆分
解决方案：对page=itinerary和localhost/MercuryWebTours(main URL)进行拆分
Windows Resources
现象：与磁盘的交互较平稳、Private Bytes看内存总体较平稳、Processor Queue Length看排队值为6.121
分析：Processor Queue Length看排队值较大说明cpu有点处理不过来了，存在瓶颈，io与内存较平稳
结论：IO、内存较平稳，但cpu存在瓶颈
解决方案：对cpu进行升级
三、结果分析总结以及解决方案
webtours存在的问题：通过上述各图表的分析，我们可以知道webtours存在的问题包括：网络方面、服务器处理能力太差了、cpu存在瓶颈以及代码方面存在问题
调优：
调优思路：服务器硬件-〉网络-〉服务器操作系统（参数配置）-〉中间件（参数配置，数据库，web服务器等）-〉应用（SQL语句、数据库设计、业务逻辑、算法等）
服务器硬件：服务器处理能力太差了就可以从服务器硬件和软件方面进行调优，硬件方面就是对硬件进行升级（内存、cpu等进行升级）、使用多台服务器进行负载均衡
网络:对宽带进行升级
服务器软件：使用缓存、设置参数（设置configuration下的 Max HTTP Connections 和Allow Keep-Alive connections），webtours的服务器是windows，可以换成linux，因为linux的性能比windows较强
中间件：中间添加个缓存服务器
代码:上面说了pl程序文件可以进行拆分、业务逻辑算法较复杂、可以对业务逻辑算法进行优化，减少代码冗余
数据库：webtours没有数据库所以数据都保存在文件中，以后数据量大时必然也是一个瓶颈，可以添加一个数据库服务器，使用mysql数据库可以进行如下调优：
1、硬件调优
2、修改mysql进程
3、优化mysql查询
一、硬件调优
先看看硬件调优吧。这个有两方面你可以考虑，首先对现有硬件条件进行修复，能调整的调整，能替换的替换，例如你可以把中央处理器（CPU）或磁盘速度加倍，也可以让内存增大 4 到 8 倍。或者你可以替换掉有问题的硬件。其次，如果你的预算没有限制，那么你干脆可以无限制的增加你的服务器，不过这种解决方案也就仅限于此了。
二、修改mysql进程
也就是对mysqld进行调优，对这个进程进行调优意味着适当地分配内存，并让 mysqld 了解将会承受何种类型的负载。加快磁盘运行速度不如减少所需的磁盘访问次数。类似地，确保 MySQL 进程正确操作就意味着它花费在服务查询上的时间要多于花费在处理后台任务（如处理临时磁盘表或打开和关闭文件）上的时间。
三、查询优化
这个是最好的方法啦，这意味着对表应用了适当的索引，查询是按照可以充分利用 MySQL 功能的方式来编写的。可以配置 mysqld 来报告可能需要进行调优的查询。
如何调优呢，具体方法如下：
a、记录慢速查询
啥是慢速查询呢：执行时间超过给定时间范围的查询就称为慢速查询。您可以配置mysqld 将这些慢速查询记录到适当命名的慢速查询日志中。然后你日后可以通过观察这些日志，来决定哪些部分需要调整。
b、对查询进行缓存
又是缓存哈，大多数应用都严重依赖于数据库查询，查询的大致过程如下:
程序发出查询请求->数据库收到指令对查询语句进行分析->确定如何查询->从磁盘中加载信息->返回结果
如果你反复查询，他就反复执行这些。MySQL 有一个特性称为查询缓存，他可以将查询的结果保存在内存中，在很多情况下，这会极大地提高性能。不过，问题是查询缓存在默认情况下是禁用的。
c、强制限制
您可以在mysqld 中强制一些限制来确保系统负载不会导致资源耗尽的情况出现。
d、缓冲区和缓存
mysql有超过100个可以调节的设置，要记住那么基本是不可能的，但是幸运的是你只需要记住很少一部分你就可以基本满足你的需求了，我们还可以通过“SHOW STATUS”命令来查看mysql是否按照我们的期望运行着