性能测试知识科普(一)

简介: 换成高速收费站的场景,就是车到了收费窗口,我刷卡扫码支付,然后抬杆放行直到车出去下一个车进来。这个过程的耗时就是所谓的响应时间。至于我们常见的平均响应时间和99响应时间,只是不同维度的统计方法而已。

前几天在技术交流群,有同学问了一个性能问题,由此引发了很多同学的追问:


  • 并发到底是什么鬼?
  • 怎么判断系统到了性能瓶颈?
  • 监控那么多指标到底关注哪些?


应这些同学要求,这篇文章做个性能测试理论知识扫盲科普,不讲似是而非的理论,就聊一些工作中很常见的术语。


我一直觉得性能测试是很简单的事情,但工作中遇到很多同学,基本都是找个工具无脑堆并发,然后压测统计数据完事。我觉得问题并不是这些同学技术不够好,而是对一些基础的知识理解有所误差,或者换句话说:


大脑:我学会了。

实践:不,你还没学会。


在学习一门新技术或者在工作实践中,我一直提倡的是“工欲善其事,必先利其器。欲利其器,必晓其理作为性能测试知识科普的第一篇入门文章,我想聊聊大家都很关心的几个词:并发、TPS、响应时间


或者站在我的角度来说,搞明白了这三个词,性能测试就入门了。当然并不是单纯的明白术语的理论解释,而是知道它们三者之间的关系,彼此的依赖影响。


收费站的故事


先给大家举一个很经典的例子:高速收费站的故事。


假设现在有一个高速收费站,有4个收费窗口,每个窗口平均5秒通过一辆车。


其中有2个ETC窗口,平均1秒通过一辆车。


现在有100辆车同时到达收费站,需要多久可以完全通过?平均每辆车通过耗时多久?如何提高通过效率降低通过耗时?


以上面的例子来讲,假设它是一个性能需求,你看到的第一眼会想到哪些知识点,要考虑哪些因素?如果是我的话,我大概会想到下面一些因素:


收费站是服务器,4核的配置,官方(或者说历史数据表明)性能表现是平均响应时间=5秒;


2个ETC窗口,可能是请求打标做了业务(或者技术上的)优先级区分,要考虑这里的具体场景;


100辆车同时到达,是压测工具模拟的“并发数”,但实际并不是服务器单位时间内同时处理的请求;


需求问的是通过的总耗时和平均响应时间,以及如何提高通过效率降低通过耗时。这个问题怎么解决?


如何理解并发?


严格意义上讲,并发指的是服务端单位时间内接受到了多少请求,这是衡量系统面临多大压力的一个重要指标。


但现实情况却是,很多同学拿着常见的压测工具,用并发线程数/VU等作为所谓的并发数来理解。就像上面的高速收费站故事,你以为的并发是100辆车,其实对系统来说真正的并发是四个收费窗口。


因此,我建议各位同学在学习性能测试的时候要明白一点:所谓的用工具模拟并发数,其实只是为了满足让系统承受足够压力的动作。


如何理解TPS?


TPS,官方解释是每秒事务数,它描述了系统在单位时间内完整的处理完一整个业务请求的过程。以上面的高速收费站为例,有4个收费窗口,每个窗口平均5秒通过一辆车。其中有2个ETC窗口,平均1秒通过一辆车。


请问整个收费站的TPS是多少?计算方式:(4个收费窗口*1)/5秒=0.8。


当然,这里要区分业务场景,如果单独论ETC场景,2个收费窗口,1秒1个,那TPS=2。


大家明白了吗?在真正的性能测试中,TPS是需要考虑到具体的业务场景,并且要求请求在逻辑上被完整处理。从技术角度来说,如果是写的请求,需要确保数据库或者缓存的数据做了符合业务逻辑的变更。


如何理解响应时间?


聊完了并发和TPS,接着聊响应时间。何理解响应时间呢?这个要从2个维度来理解。


  • client:客户端发起请求,通过网络传输到服务端,服务端按照逻辑处理完成,并返回response给到客户端。
  • server:从接受到请求开始处理,到完成逻辑处理并从服务端发出,OK到此结束,一个统计区间完成。


换成高速收费站的场景,就是车到了收费窗口,我刷卡扫码支付,然后抬杆放行直到车出去下一个车进来。这个过程的耗时就是所谓的响应时间。至于我们常见的平均响应时间和99响应时间,只是不同维度的统计方法而已。


三者间的关系和影响


如何提高通过效率降低通过耗时,这是上面的问题。


在解决这个问题之前,不妨代入一下真实的高速收费站,我们想象如下几种情况。


  • 100辆车同时到达,但只有四个收费窗口,需要排队按顺序进入,这是队列机制;
  • 100辆车同时到达,但只有四个收费窗口,万一工作人员换班午休,这是系统维护;
  • 100辆车同时到达,但可能有交警检查,四个收费窗口,只有2条道通过,这是限流;
  • 没有安装ETC的车走了ETC的车道,过不去,需要倒车换到其他收费窗口,这是异常;


看完了上面的几种情况,我们来看下如何理解三者间的关系和影响。


  • 提高通过效率,可以增加收费窗口(服务器升配置,4核变8核);
  • 提高通过效率,可以让更多车主安装ETC(技术优化,都用缓存);
  • 提高通过效率,可以通过某种机制确保车道不走错(异常处理,快速失败或放行);
  • 提高通过效率,可以通过7*24小时轮班确保收费窗口正常提供服务(服务的可用性);


还有其他提高通过效率降低通过耗时的方法吗?有!


  • 高速3车道变6车道(扩展网络带宽);
  • 多开设几个不同的收费站(服务扩容);
  • 大货车小客车车道时速区分(分流机制);
  • 大货车小客车走专门的收费站(服务分组);


最后总结


  1. 真正的并发是服务端单位时间内接收并处理的请求数,并不是工具模拟的并发线程数。
  2. 其他条件不变的情况下,要提高TPS降低响应时间,最简单的办法是升配+扩容+缓存。
  3. 高并发/高性能/高可用其实是指用更少时间处理更多请求,且服务长期提供正常服务。


这篇文章的目的是通过一个很典型的例子帮助学习性能测试的同学理解几个常用的术语,下篇文章,我会聊聊常用的性能测试策略。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
存储 SQL 数据采集
性能测试知识科普(七):监控能给你带来什么
当然这些指标是我们日常工作中经常遇到和会关注的,但实际上在性能测试过程中,要根据不同的业务场景、技术架构以及问题表现来关注分析不同的指标。而不是只关注自己看到的指标,填充到表格里提交一份所谓的压测报告就完事的。
性能测试知识科普(七):监控能给你带来什么
|
缓存 测试技术 数据处理
性能测试知识科普(六):三大模型
在性能测试工作中,业务模型、流量模型和数据模型是至关重要且必须在项目中构建的,否则很可能导致测试的场景和实际差距很大,测试结果也无法为性能分析和优化提供足够有说服力的支撑。为了便于大家理解三大模型
性能测试知识科普(六):三大模型
|
运维 监控 中间件
性能测试知识科普(五):能力分层
前面的文章分享了性能测试中的核心术语和指标、常用测试策略、压测工具选型以及性能需求分析的内容。写这篇文章的初衷是昨天有同学咨询我,希望通过付费方式让我教她性能测试,可以达到独立owner项目的程度。
性能测试知识科普(五):能力分层
|
缓存 负载均衡 监控
性能测试知识科普(四):分析需求
为了避免某个可用区由于网络硬盘等原因损坏导致服务不可用,跨可用区的服务部署是一种常见的容灾手段。
性能测试知识科普(四):分析需求
|
数据可视化 测试技术
性能测试知识科普(三)
还有在一些技术交流群,很多同学会说自己遇到的问题,如不知道怎么用jmeter参数化,locust的压测结果图表怎么看,怎么写gatling的压测脚本等等。并不是说觉得用工具low,而是遇到问题,我个人觉得首先应该分析问题,找到解决方法和策略,然后寻找合适的工具来辅助自己快速解决问题。
|
负载均衡 测试技术
性能测试知识科普(二)
在聊测试策略之前,很有必要聊聊性能测试的目的,或者性能测试的本质是要做什么,解决什么问题。只有想明白这点,后面的需求分析、工具选型、制定测试策略才能更好的开展。
性能测试知识科普(二)
|
8月前
|
关系型数据库 MySQL Java
【JMeter】(3)---MySQL压测
【JMeter】(3)---MySQL压测
180 0
|
8月前
|
JSON Java 测试技术
【JMeter】(2)---HTTP压测
【JMeter】(2)---HTTP压测
103 0
|
6月前
|
消息中间件 弹性计算 Java
使用阿里云性能测试工具 JMeter 场景压测 RocketMQ 最佳实践
使用阿里云性能测试工具 JMeter 场景压测 RocketMQ 最佳实践
|
8月前
|
XML 前端开发 测试技术
使用 jMeter 对 SAP Spartacus 进行并发性能测试
使用 jMeter 对 SAP Spartacus 进行并发性能测试
78 0