性能测试爬坑之路18 Analysis--前端性能指标分析

关住 公 纵 号 “  阿蒙课程分享    ”  获得学习资料及趣味分享　

 

   这届看我们看一下性能指标，跟工具无关的一些东西，前端的一些性能指标，他们的作用和价值所在，在web 测试里面我们有专门的一门课程叫 web 前端分析，里面的一些性能指标已经做了一些讲解了，这边我们结合着性能测试，纯粹从性能测试角度再来巩固一下性能指标，把我们的web 前端分析 和 性能测试的前端分析结合起来掌握，那么前端这一块我们都可以搞定，没有问题了

     前端的性能指标有哪些？为什么要称之为前端？所谓前端，他其实主要是从用户角度感知到的性能指标，与之对应的后端的性能指标纯粹是一些服务器端的性能指标，我们的界面，我们的接口，我们跟用户交互的这些东西都是可以从前端的角度，包括 load runner 这个工具本身，他也是一个模拟客户端的工具，他也是一个前端的工具而已

    1.那么从一个用户的角度他感知到的性能指标有哪些？最简单，最容易感受到的是响应时间快慢的问题，所以响应时间是一个前端响应时间，当我这个请求发出去了，当我这个按钮点了以后，多久我才会收到服务器的相应，这个页面多久才会被渲染出来，这个过程对用户是非常非常关键的，我们的系统如果处理的不好，比如我们去访问百度的首页，很快就出来了，给用户的体验是非常好的，响应时间是很关键的前端性能指标，代表什么意义，大家已经很清楚了，不做赘述

    2.用户感觉没那么明显，但是从技术层面来说，响应时间并不是单纯的由某个服务器的响应时间决定，他有很多的因素，第二个我们关注的就是吞吐率，响应的吞吐率，什么意思?就是我们性能指标里提到的 Troughtput ,那么当然我们必须明确的知道吞吐率是什么意思，所谓吞吐率就是服务器每秒钟响应的大小，虚拟用户数多少无关，他不是说虚拟用户每分钟服务器响应的大小，评估有两个方面：

                服务器的带宽：

                    服务器无论有多少并发用户访问我，我服务器的响应到底有多大，他的跟我的服务器带宽关联性很高，如果说我这边服务器的带宽够用的情况下，比如说我们的服务器的带宽是 100 M ，这边响应的大小只有几兆，当然这个带宽我们一定换成等同的，8倍的差距，服务器的带宽是 100 兆他的传输速度其实就是 12.5兆，这里的相应的大小是以字节为单位的，带宽是以位为单位的，如果相应的大小，小于服务器的带宽，那么证明我们服务器的带宽不是问题，你有这么多虚拟用户来访问我，我的服务器是撑得住的，比如说我现在有 1000 个用户访问服务器，那服务器的带宽是 100 M 就是 12.5 M 的传输速度，这里 1000 个用户访问服务器他的吞吐率是 10M     基本上快到极限了，但是还是扛得住，如果他的吞吐率只有5兆，那么服务器的带宽就绰绰有余，带宽这么贵，那就没有必要浪费这么多带宽，我们只需要申请一个 6、7 兆的带宽就可以了，换算成6、7兆的传输能力的带宽就可以了，那就是 50兆，他可以帮我们评估服务器的带宽，那么同样的我们这个响应的时间，和响应的吞吐率，他到达了，从服务出来是每秒钟吞吐率，如果再除以虚拟用户的数量，那是不是就是客户端的带宽了，这样就可以评估客户端用多大的带宽是合理的，但客户端的带宽的评估有没有必要非用吞吐率这个指标，没有太大必要，只不过附带有这样的功能而已，我们客户端的带宽到底有多少合适？试试上我们完全知道，当我们用户访问我们某一个页面的时候，我的这个页面大小到底有多大，比如说这个页面，他的响应的大小就是 160 多k, 如果是 2 M 的带宽，基本上就可以达到 256 k 的速度，也就可以了，一个 2 兆的带宽就可以在一秒钟左右的时间就可以把这个页面下载下来并加载上，我们通过发送一个页面请求，看一下响应的大小，就可以很简单的评估出来，客户端的带宽是多少是合适的，这就是关于吞吐率他的一个作用。如果我们发现服务器的带宽跟响应带宽他们两个相当了，这个时候就会影响到我们的相应时间，因为带宽不够用了，传递的就会慢一些，不是客户端的带宽，而是服务器出的带宽比较慢了，那他就会影响这个响应时间，所以这两者单纯的看这两个指标，我们并没有获取一个很完整的请求，所以这两个指标我们都应该去考虑，从前端的角度，吞吐率他也是从前端的，用户的角度感受到的服务器给我的响应的大小，那么如果我们去监控服务器端的吞吐量，就不是客户端工具，或者是前端的相应时间判断来完成，而是我们去监控服务器端的硬件指标，这个带宽，就是监控服务器的网卡了，这就是监控到的服务器更真实的带宽，上面的那个是从用户角度监控到的带宽，但是可以给我们提供参考

     3. 每秒的事务数， Transaction per second  他的专业术语叫 TPS ，很关键的一个指标，这也是一个前端的视角评估出来的一个性能指标，这个事务是跟我们的脚本中定义的事务是直接关联的，脚本里面怎么定义事务的，手机数据就是按照什么样的事务来收集，所以 TPS 他不像我们传统意义上的认为，他是处理某一笔业务的，因为他是从客户端定义的事务，他不像服务器那边，也不像数据库那边，写一批 sql 语句叫一个事务，他不是这么一个概念，当然你也可以用 TPM 每分钟处理的事务数，你用 TPH 每小时的事务处理能力你可以进行事务处理能力评估的，就是除以3600，所以这些都不是问题，我们要讲的是，每秒事务处理数他的作用在哪里，为什么从前端的角度还要特别关注一下 TPS ？我们需要通过 TPS 这个重要的性能指标来设计性能需求,什么意思？咱们的TPS 每秒的事务处理能力，是直接和我们的性能需求先关的，他的原因在于，我们的性能需求没有办法严格从客户端的角度来设计，比方说我们来设计同事满足 1000 个用户是否是我的一个合理的用户数，我到底多少用户是合理的，其实我们是很难考量的而我们通过事务处理的能力，我们就可以很好的考虑，因为，虽然他是一个前端的指标，但是这个指标他也可以传递到后端去，每秒钟处理了100 个登录，这100个登录在服务器那边是不是同样还是100 个登录的请求，一样的道理，前端的角度后端都是一样的，评估的角度，获取的系统的资源都是一样的，所以全端用 TPS ，后端用TPS ,那么我们就可以，比如说我们不知道到底支撑多少用户，但是我要求系统每天处理 5 万笔业务，5万笔事务，你要觉得登录是个事务，你就定义登录是个事务，你要是觉得登录和打开首页是个事务，你就可以定义登录和打开首页的组合是个事务，都可以，我们就可以从事务的处理能力来提我们的性能要求了，而不见的是我们从用户的数量来提我们的性能要求了，后边我们会专门分析我们这些东西会很难提，

    4. HPS  每秒的点击数，就是针对我们性能测试的指标来说，其实他的作用不太大，他不能很好的帮助我们分析，也不能帮助我们找到瓶颈，也没有办法让用户直接感受到，如果说真的是他的作用，在哪里呢?其实就是 web 前端分析一样，我们要尽量的减少 http 请求，所以我们希望的其实是HPS 越快越好，但是尽量不要太大，一秒钟处理多少请求，当然是越多越好，但是如果是请求数多了，我们反过来要看到底是我们的页面设计的有问题，比喻一些小的http 请求要不要进行合并，所以每秒点击数单纯放在这里没有太多的参考价值，他最多让你感受到，如果响应时间很快，那么发请求的速度就会很快，如果 HPS 很大，随着虚拟用户数增加，HPS 增加，随着 虚拟用户数 不变，HPS 不变，通过虚拟用户数做一个分析之后，我们大概的就能够了解这个系统还挺不错的，没有达到有瓶颈的情况，他就大概让我们得出这样一个模糊的结论，所以这个指标相对并没有那么重要，他只是用来评估客户端虚拟用户数，发请求的频率，发请求的频率其实是取决于服务器处理请求的速度，这个请求只有被处理过后你才能发下一个请求，当然单纯从指标上来说，我们希望他越高越好，点击数越多越好，但是这个点击数它取决于虚拟用户的数量，十个虚拟用户和一万个虚拟用户每秒点击的数量肯定是不一样的，所以第一个它取决于用户的数量，第二个取决于服务器的处理时间，处理速度，处理的速度越快，这里每秒发的越快，他的 HPS 越高，服务器处理一个请求要半天，这里 HPS 也会相应的减少，所以HPS 我们唯一可以做的就是做一个对比，我们举个例子，比如说我们这个系统有 1.0 和 2.0 两个版本，我2.0的版本相对性能是做过优化的，我现在通过 HPS 来对比一下，比如说我的 1.0 的版本并发 1万个用户他的 HPS 是多少，2.0 的HPS 是多少，如果 2.0 的HPS 要大于 1.0 的HPS 我觉得 2.0 的性能要好于 1.0 ，但是这种对比，为什么非滴用 HPS 这个指标对比？很多指标都可以对比的，所以他的作用没有那么大，我们了解一下就可以了，我们后面不会花专门的时间来介绍这个指标

    HTTP response Second  这个跟 HPS 相应的，不做过多的介绍

    connection 连接数，到底一共有多少个连接，跟我们的虚拟用户数是相关的，所以也没有什么特别要介绍的， window 资源，window resource 这些与后端有关的指标，所以我们专门放到后端的性能指标专门给大家做分析，基本上从前端的角度来说，我们用到的性能指标就这么几个，那么就这样的一些指标，他单纯放在这边，只能让我们感受到用户体验好不好，但是至于通过这些指标评估出来后台系统有问题，实际上很难评估出来的，我们最多只能通过这个 analysis 组件里面他们通过关联图进行一些趋势的分析，来看看虚拟用户值增加的时候，他的趋势是怎么样，虚拟用户数保持不变他的变化趋势是怎么样，可以预判服务器端的处理情况，这个预判我们后面有专门一节课来把前端后端都讲完了以后，专门有一节课，结合我们的性能测试方案和报告来打开一个比较严谨的性能测试报告，再来给大家讲这种规律，对于前段的性能指标的一个作用是这些