「性能测试实战30讲」之问题问答整理五

01

如何理解“服务端的并发能力”这一描述？

02

我为什么不提倡使用“绝对并发”和“相对并发”的概念呢？

03

我们为什么不推荐用 cpu 来计算并发数？

第一个问题：如何理解“服务端的并发能力”这一描述？ 首先我们从数据视角来理解，可以把服务端程序用一个模型来看待，即由「网络 API 请求」所驱动的。 服务端的领域特征是大规模的用户请求，以及 24 小时不间断的服务。但某种意义上来说更重要的原则是：坚决不能丢失用户的数据，即他认为已经完成的业务状态。服务端必须保证其业务状态的可靠性，这时业务状态才持久化写入到外存。所以对于服务端来说，存储至关重要。它不只是极大地解放了处理效率，也是服务端的性能瓶颈所在。几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。 在衡量服务端的性能，我们还是要服务端视角来看，主要以 TPS 为主来衡量系统的吞吐量，如果有必要用并发用户数来衡量的话，需要一个前提，即响应时间（RT），因为在系统压力不高的情况下，将思考时间（等待时间）加到场景链路中，并发用户数基本还可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义，也不专业。 第二个问题：我为什么不提倡使用“绝对并发”和“相对并发”的概念呢？ 我觉得一切的前提是业务价值需要。如果没有足够的价值，那么可读性才是第一，对这种难懂的概念很反感，要知道的其会加重内部沟通的难度，得不偿失。如果没那个价值，简单才是王道。 第三个问题：我们为什么不推荐用 CPU 来计算并发数？ 比如单核CPU情况，实际上是只有一个的，在一个特定时刻也只可能有一个程序跑在一个CPU上(因为寄存器只有一组)，但是我们在上层观察到的却是系统上好像同时运行着那么多的程序，这实际上是操作系统用进程这个概念对CPU做的抽象。 同时如果你了解「阿姆达尔定律」，就知道多处理器并行加速，总体程序受限于程序所需的串行时间百分比，超过一定的并行度后，就很难进行进一步的速度提升了。并不符合线性关系，也无法估算的。 再说服务端程序性能依赖不仅仅是底层的硬件，其依赖的基础软件还包括：操作系统、编程语言、负载均衡、中间件、数据库或其他形式的存储等。在第一个问题中提到了几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。 最后，还是需要回到第一个问题，即由「网络 API 请求」所驱动的模型上来。

作者回复: 不仅深得真传，还扩展了。我看好你哦。

问题一，如何理解“服务端的并发能力”这一描述。对于web项目而言，服务端是整个项目的关键，是咽喉要道，因此也是性能测试的重点。测试目的当然是要摸清这个要道能同时走多少人（注意这里的人不是在线用户数并发用户数，而是服务器能处理的事务），因此TPS最能描述服务端的并发能力。虽然老师一直强调压力机并发线程数不是关键，但是公式表明其与TPS、响应时间有着不可分割的联系，还需要好好体会并运用。很期待基准测试以及如何判断响应时间、TPS合理的后续讲解。

问题二，为什么不提倡使用“绝对并发”和“相对并发”的概念呢？老师讲得很清楚了，这两个概念对于我们关心的性能并没有太多的帮助，反而让人有点无从使用。在线人数，并发数，并发度简洁明了，很好理解，有利于沟通，是性能测试必备指标之一。

问题三，为什么不推荐用 CPU 来计算并发数？并发数是业务逻辑层面的，而CPU只是众多软硬件环节中的一环，即使可以借鉴，肯定也是很粗略的估计，在实践中使用价值不大，没有推广使用的必要。

作者回复: 这个理解太正确了。比我写的好。

针对吞吐量，根据你的公式， 我没计算出跟jmeter一样的值。我用jmeter 去压测，并发数200，平均响应时间是1655.65ms， jmeter最后的吞吐量给的是20.71/s，由于留言不能发图片，我只能用文字了。 针对这个课程，老师能不能创建一个微信群，这样更加方便沟通。

作者回复: 你这个结果看起来是不太对。要不你加我微信发详细点的数据我看看：Zee_7D

老师我们不讲性能测试的基础吗？录制脚本，写脚本及案例这些吗？

作者回复: 后面有几篇讲到录制脚本，编写脚本。如果你要非常完整的，那就看帮助就行。不会的可以问，毕竟这个专栏不是工具类的。

并发用户数（TPS）是 396.2TPS。如果并发度为 5%，在线用户数就是 396.2/5%=7924。这句话我不太明白。假设这是登录场景，对应我的真实场景就是7924的用户同时登录？但是1秒可以处理约400个请求。那不是某在排队了？

作者回复: 对应到真实场景是说现在有7924个用户在线，而同时在执行登录这个操作的只有196.2个人。

测试时把tps调到最大，依据什么来调中间件的线程数为合理值了

作者回复: 这个非常简单，压力过程中观察线程的使用率和上下文切换频率就阔以啦。

1.如何理解服务端的并发能力：对于新手容易误解工具上的并发即常说的并发概念；因此延伸并发是服务端的并发能力，也是最确切的衡量依据，而非工具上的数值； 2.为什么不提倡使用绝对并发和相对并发：同上，统一简单易理解的指标即可，最终结果也不需要去区分相对和绝对，徒增烦恼 3.为什么不推荐用cpu来计算并发数：额，这道题不是特别清晰；强答一波：除了预期被测请求要用到cpu，还有其他计划外不可避免的cpu消耗；因此cpu不能完美诠释并发数

作者回复: 基本正确。第3个主要是CPU不能代表系统的综合能力。

如何理解“服务端的并发能力”这一描述？ --- 个人理解，服务端的并发能力就是说服务处理的能力，即其可以处理的请求量； 为什么不提倡使用“绝对并发”和“相对并发”的概念呢？ --- 概念容易使大家混乱，不利于团队之间的沟通；再者，没必要去纠结绝对并发还是相对并发，我们关心的使服务端处理的请求量； 为什么不推荐用 CPU 来计算并发数？ --- 用cpu计算并发数，感觉没有理论依据

作者回复: 第三点需要稍微纠正，不是没有理论依据。是这个依据还不足以支撑计算业务的性能TPS。

有个疑惑请教下老师，按照tps算服务器的压力话，这个tps的数值依据怎么定呢，因为压力线程数增加，可能会导致tps的下降，那应该按照多少tps来定义并发用户线程数呢？

作者回复: 把TPS调到最高就好。压力大，响应时间长了，tps下降了，那服务端的处理能力明显是下降了嘛。

不是用TPS来定义并发用户线程数，这两者的关联关系，只有在执行过程中确定，没有谁定义谁。

服务端的并发能力 我认为是指在具体业务场景下，整体服务的可支持的并发量，其中并发量不等于在线用户量。具体多少并发我认为可以取自线上真实流量高峰李全

作者回复: 阔以滴。