《LoadRunner性能测试巧匠训练营》——1.5 性能测试模型分析-阿里云开发者社区

开发者社区> 华章计算机> 正文

《LoadRunner性能测试巧匠训练营》——1.5 性能测试模型分析

简介:
+关注继续查看

本节书摘来自华章计算机《LoadRunner性能测试巧匠训练营》一书中的第1章,第1.5节,作者:赵 强 邹伟伟 任健勇 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.5 性能测试模型分析

经过上面的学习,小白对基本的性能测试概念等有了深刻理解,为了能把这些概念应用到实际项目中,小白开始对典型的性能测试模型进行学习,逐步把概念、指标运用起来,并培养自己的观察分析能力。
1.5.1 曲线拐点模型分析
对于初学者来说,培养观察与分析思想是很重要的,首先来看一张典型的曲线拐点模型图,如图1-2所示。


94266dd0b6b95a629584abac5417a590eaeb1786

分析图1-2最好是先看一个个指标,然后再综合分析,这样的步骤更容易理解,思路也更加清晰明了。接下来就和小白一起来分析吧,分析思路如下。
1)X轴代表并发用户数,Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
2)然后一个个分析,根据前面学习的性能术语与指标进行理解,随着并发用户数的增加,在轻压力区的响应时间变化不大,比较平缓,进入重压力区后呈现增长的趋势,最后进入拐点区后倾斜率增大,响应时间急剧增加。
3)接着看吞吐量,随着并发用户数的增加,吞吐量增加,进入重压力区后逐步平稳,到达拐点区后急剧下降,说明系统已经达到了处理极限,有点要扛不住的感觉。
4)同理,随着并发用户数的增加,资源利用率逐步上升,最后达到饱和状态。
5)最后,把所有指标融合到一起来分析,随着并发用户数的增加,吞吐量与资源利用率增加,说明系统在积极处理,所以响应时间增加得并不明显,处于比较好的状态。但随着并发用户数的持续增加,压力也在持续加大,吞吐量与资源利用率都达到了饱和,随后吞吐量急剧下降,造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数,因为各种资源都利用充分,响应也很快;而重压力区与拐点区的交界点就是系统的最大并发用户数,因为超过这个点,系统性能将会急剧下降甚至崩溃。
分析到这里,小白终于找到点成就感了,同时也庆幸自己没有忽略基础,看来基础对于日后的学习有着重要意义!
1.5.2 地铁模型分析
和绝大部分人一样,小白每天都要乘坐地铁上下班,那么就拿地铁来分析,再次深刻理解下性能。早上乘坐地铁上班,最典型的就是北京地铁1、5、10、13号线等,人多得简直没法形容!为了方便理解分析,先做如下假设。

  • 某地铁站进站只有3个刷卡机。
  • 人少的情况下,每位乘客很快就可以刷卡进站,假设进站需要1s。
  • 乘客耐心有限,如果等待超过30min,就会暴躁、唠叨,甚至选择放弃。

按照上述的假设,最初会出现如下的场景。
场景一:只有1名乘客进站时,这名乘客可以在1s的时间内完成进站,且只利用了一台刷卡机,剩余2台等待着。
场景二:只有2名乘客进站时,2名乘客仍都可以在1s的时间内完成进站,且利用了2台刷卡机,剩余1台等待着。
场景三:只有3名乘客进站时,3名乘客还能在1s的时间内完成进站,且利用了3台刷卡机,资源得到充分利用。
想到这里,小白越来越觉得有意思了,原来技术与生活这么息息相关,真的可以快乐学习哦。随着上班高峰的到来,乘客也越来越多,新的场景也慢慢出现了。
场景四:A、B、C三名乘客进站,同时D、E、F乘客也要进站,因为A、B、C先到,所以D、E、F乘客需要排队,等A、B、C三名乘客进站完成后才行。那么,A、B、C乘客进站时间为1s,而D、E、F乘客必须等待1s,所以他们3位在进站的时间是2s。
通过上面这个场景可以发现,每秒能使3名乘客进站,第1s是A、B、C,第2s是D、E、F,但是对于乘客D、E、F来说,“响应时间”延长了。
场景五:假设这次进站一次来了9名乘客,根据上面的场景,不难推断出,这9名乘客中有3名的“响应时间”为1s,有3名的“响应时间”为2s(等待1s+进站1s),还有3名的“响应时间”为3s(等待2s+进站1s)。
场景六:假设这次进站一次来了10名乘客,根据上面的推算,必然存在1名乘客的“响应时间”为4s,如果随着大量的人流涌入进站,可想而知就会达到乘客的忍耐极限。
场景七:如果地铁正好在火车站,例如,著名的北京西站、北京站。每名乘客都拿着大小不同的包,有的乘客拿的包太大导致卡在刷卡机那(堵塞),这样每名乘客的进站时间就会又不一样。
小白突然想到,貌似很多地铁进站的刷卡机有加宽的和正常宽度的两种类型,那么拿大包的乘客可以通过加宽的刷卡机快速进站(增加带宽),这样就能避免场景七中的现象。
场景八:进站的乘客越来越多,3台刷卡机已经无法满足需求,于是为了减少人流的积压,需要再多开几个刷卡机,增加进站的人流与速度(提升TPS、增大连接数)。
场景九:终于到了上班高峰时间了,乘客数量上升太快,现有的进站措施已经无法满足,越来越多的人开始抱怨、拥挤,情况越来越糟。单单增加刷卡机已经不行了,此时的乘客就相当于“请求”,乘客不是在地铁进站排队,就是在站台排队等车,已经造成严重的“堵塞”,那么增加发车频率(加快应用、数据库的处理速度)、增加车厢数量(增加内存、增大吞吐量)、增加线路(增加服务的线程)、限流、分流等多种措施便应需而生。
分析到这里,小白可以熟练地把性能指标与场景结合运用起来了,初步学习成果还是不错的。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
深度分析Java的ClassLoader机制(源码级别)
深度分析Java的ClassLoader机制(源码级别) 写在前面:Java中的所有类,必须被装载到jvm中才能运行,这个装载工作是由jvm中的类装载器完成的,类装载器所做的工作实质是把类文件从硬盘读取到内存中,JVM在加载类的时候,都是通过ClassLoader的loadClass()方法来加载class的,loadClass使用双亲委派模式。
1250 0
TokuDB · 特性分析 · 导入数据大杀器:Loader
Loader简介 Loader设计思路是把<pk_key,pk_value>二元组缓存在内存中,对每个索引在后台计算索引key。等所有的数据插入操作完成后,对每个索引进行排序,最后用排好序的索引key数组建立FT文件。 创建FT的过程:依次创建每个叶子节点(leaf node)和中间节点(internal node)。最后维护元数据,这里包括index descriptor,bloc
958 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
4512 0
10059
文章
0
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载