性能测试爬坑之路 16 Analysis 结果分析工具二

 

Analysis summary 是总结性的报告，他告诉我们测试了什么脚本，花了多长时间，有的最多的虚拟用户是多少个？

 

总的吞吐量是多少个字节，这里的吞吐量和吞吐率其实是一个很泛的概念，这里指的是服务端给客户端响应一个流量的大小，

这个能让我们查看

average throughput 平均的吞吐量

total hit 总的点击数，也就是我们一共给服务器发了多少个请求，

average hits 每秒钟发了多少个请求，

我们输入一个网址，这里列表里的都是hits,每个 hits 都是一个请求，就是一次点击,虽然我们只输入了一个网址，但是这个页面又很多的资源需要 got 到，

 

这里是我们的一个事务的摘要，总的成功了 651 个事务， 失败了  7 个事务，中途停止了  8个事务

线面的事务列表有一行，最小的响应时间，平均的响应时间，最大的响应时间，响应时间的标准差，标准差越小越好，越小最大值和最小值与平均值之间的差距越小，证明响应时间比较集中，比较稳定

90 percent : 90% 的响应时间 小于 19.879

还有成功了过少，失败了多少，停止了多少，这是用于统计事务的摘要的，这里浏览一下就好了

302 redirect

这边列出来的是服务器端 服务器端响应的一个状态，200 是正常的，也会出现其他的状态，一旦获取到都会列出来，

我们可以在这里查看服务器返回的状态是否正常，因为在我们对服务器施加压力的时候服务器可能会出错

这些事总结性的，下面的 graphs 是比较详细的报告

我们可以通过 在 Graphs 上右键 【add new item】--》 【add new graph】添加新的图表，

我们这里先随便添加一个跟事务有关的

Transactions per Second 事务的每秒的处理量

 

Transactions Response Time Under Load

Transactions Response Time (Percentile)

Transactions Response Time (Distribution)

这个我们后面会讲到，这些都是从不同的角度分析数据

关于

Throughput 吞吐量

HTTP Status 状态码的

Connections 链接的

我们都可以看一看

这个 Web Page Diagnostics 是 Web 页面诊断细分的一个分析，类似于我们前面学的一种  web 前端分析的一种，我们先随便添加一种（第一个）进去

Web page diagnostics  web 页面的细分图

page component breakdown web 页面组件的细分图

page download time breadown  页面下载的细分图

time to first buffer breakdown  从我们请求发送完到获取到响应的第一个字节整个过程所花费的时间，这个时间基本上接近我们客户端发请求到我们服务处理的这个时间，但是这些数据( web page diagnostics )其实是有问题的,这个问题出现在 我们 web 页面信息收集的很频繁，而且数据量很大，所以 loadrunner 并没有完全的收集这些数据，其实他只收集了这些数据的 10% ，而且是采样收集的，所以这 web 页面诊断图里的数据不是特别的准确，仅供参考，甚至你会看到一些，比如说响应时间你会看到，做一个事务我大约 1 秒钟，但是在 web 细分图里面告诉我做这个事情花了 3 秒多，什么原因？他采集的是一些零散的数据，而不是所有的，完整的数据分析的结果，10% 在我们的 controller 里面是有一个设置的，

【diagnostics】-->【configuration】

下面这个是系统资源

这是关于加载图表的一个功能

加载完了，这些图标在这里我们一定要静下心来，发现他的规律，找到他的价值，我们就带领大家做到这些

我们开始过一下这个图标

虚拟用户数，这里跟我们 controller 里面场景设计基本类似，有一点点的差别

这张图单独放在这里一点用处都没有，这张图放在这里，没有意义，他的意义在于将虚拟用户的变化趋势跟其他图表变化趋势结合起来，看这种趋势，我们之前讲过，我们为什么用 rump up 这个过程？原因就是以来我们可以模拟真实用户场景二来我们可以对其他的图表进行关联分析，比如说我们看 虚拟用户上升的时候我们看 CPU 、内存是不是在上升，或者我们看响应时间在上升，要去找他们的关联关系，这张图跟其他图结合起来才有价值

hit percent 每秒的点击数，这个图单纯的放在这里意义也不是太大，还是要和其他图结合，你看，我们这里虚拟用户数越多的时候我们这里每秒点击数是不是也在增加？但是他们的趋势不完全相等，虚拟用户数越多，每秒点击的频率越高，但是高到什么程度，现在我们来想一想，虚拟用户越多，很多用户在发请求了，他的平均的点击的速度会越快，现实的结果点击频率跟用户数不是线性同步递增的，用户数多和用户数少服务器的压力是不一样的，用户数多的时候处理的速度肯定要慢一点，当这个速度慢一点，响应时间会增加，而响应时间增加了只有每秒点击数会下降，这就是前面提到的动态影响，这种动态影像的关系是最难理清楚的，后面还会有例子给大家理清楚这些东西

 

我们可以看到 吞吐率跟 HPS 趋势是很像的，请求发的越快，服务器响应的就越快，响应的越多，吞吐量就越多，这两个几乎是相对应得

 

transctions summary  事务一个摘要，有多少成功的，有多少失败的，我们看到这个可以评估我们事务的成功率，

平均事务处理时间

每秒钟处理事务的个数，平均是 1.44个，针对每一个事物都是这样的，这个 TPS 是针对所有的事务统一来计算的，所以他们都是一样的这个没有问题，就每秒钟它能处理的事务，1.44 个，也就是当我们 30个用户访问这个系统，这个系统每秒钟处理 1.44 个 登录 + 1.44 个发帖 + 1.44 个打开首页，每秒钟只能处理 1.44 个事务是不是感觉很慢，那为什么处理的这个事务的能力这么慢？这其实是需要我们理清楚的，有可能我们的用户并发数太少了，搬来并发的用户数就不多，而且我们每处理一个事务都有暂停时间，他都会用来计算他这个事务的处理的能力的，每秒钟到底处理多少个事务，比方说，他每秒钟他可能处理 10 个，但是你一会给我暂定 1 秒钟，一会给我暂停 1 秒钟，所以我一分钟本来可以处理 60 个 现在我只能处理 20 个 ,那当然速度就变慢了，但这并不能反映服务器真实的处理能力，所以这里注意一下，我们后面再回来看是什么原因，

下面这个 web 页面诊断细分图，在这里面我们就可以分类，下载的时间，组件的时间，整个全程的时间的下载时间，整个时间段，里面是每一个请求，每一个页面，我们看到的他的一个具体的响应时间，

 

登录的页面，平均的一个时间是 0.993 秒

登录成功页面 7.085 秒

跟我们的事务响应时间 9.73 秒有一点点不一样，本身他就比较不准确，这是大的页面，这个页面底下的细节

我们可以切换到这个页面详细的树状结构里面，我们可以看到这个页面下载了些图片，加载了些样式，我们也可以看到上图中，每一个细微的资源他的时间，他的文件的大小，这是更细分的细分图，然后下面有几个时间的展现标记色块，比如会所蓝色的是 first buffer 首次获取到相应的时间，然后接受整个相应所花费的时间，客户端处理所花费的时间，一些错误的处理和预处理所花费的时间，

最后一个图 windows resource 

这些都是我们监控到的 CPU 的使用率，队列的长度等等，这是这些图表，而且这些每个图标都有对应的菜单，这个下节课我们给大家讲，每个图标右键所对应的功能是什么