测试老鸟总结，性能测试三大核心指标详解，并发/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车道(扩展网络带宽)；
多开设几个不同的收费站(服务扩容)；
大货车小客车车道时速区分(分流机制)；
大货车小客车走专门的收费站(服务分组)；

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

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图