05丨指标关系：你知道并发用户数应该怎么算吗？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
在性能测试中，正确理解并发用户数与TPS的关系至关重要。本文强调了统一认识各种性能指标的重要性，以避免沟通偏差。通过案例分析，作者指出了对性能指标的误解可能导致沟通障碍和问题的发生。文章介绍了绝对并发和相对并发的概念，以及在线用户数、并发用户数的计算方法。作者强调了在性能测试中应该关注服务器端的处理能力，而不是压力工具上的并发线程数。总的来说，文章强调了在性能测试中应该使用统一的性能指标，同时强调了对并发用户数和在线用户数的正确理解和计算方法。通过示例和思考题，读者可以更好地理解并发能力描述、避免混淆概念以及不推荐使用CPU来计算并发数的原因。文章简洁明了，强调实用性，对读者在性能项目中的实践具有指导意义。
《性能测试实战 30 讲》，新⼈⾸单¥59
全部留言(151)
- 最新
- 精选
zuozewei第一个问题：如何理解“服务端的并发能力”这一描述？ 首先我们从数据视角来理解，可以把服务端程序用一个模型来看待，即由「网络 API 请求」所驱动的。 服务端的领域特征是大规模的用户请求，以及 24 小时不间断的服务。但某种意义上来说更重要的原则是：坚决不能丢失用户的数据，即他认为已经完成的业务状态。服务端必须保证其业务状态的可靠性，这时业务状态才持久化写入到外存。所以对于服务端来说，存储至关重要。它不只是极大地解放了处理效率，也是服务端的性能瓶颈所在。几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。 在衡量服务端的性能，我们还是要服务端视角来看，主要以 TPS 为主来衡量系统的吞吐量，如果有必要用并发用户数来衡量的话，需要一个前提，即响应时间（RT），因为在系统压力不高的情况下，将思考时间（等待时间）加到场景链路中，并发用户数基本还可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义，也不专业。 第二个问题：我为什么不提倡使用“绝对并发”和“相对并发”的概念呢？ 我觉得一切的前提是业务价值需要。如果没有足够的价值，那么可读性才是第一，对这种难懂的概念很反感，要知道的其会加重内部沟通的难度，得不偿失。如果没那个价值，简单才是王道。 第三个问题：我们为什么不推荐用 CPU 来计算并发数？ 比如单核CPU情况，实际上是只有一个的，在一个特定时刻也只可能有一个程序跑在一个CPU上(因为寄存器只有一组)，但是我们在上层观察到的却是系统上好像同时运行着那么多的程序，这实际上是操作系统用进程这个概念对CPU做的抽象。 同时如果你了解「阿姆达尔定律」，就知道多处理器并行加速，总体程序受限于程序所需的串行时间百分比，超过一定的并行度后，就很难进行进一步的速度提升了。并不符合线性关系，也无法估算的。 再说服务端程序性能依赖不仅仅是底层的硬件，其依赖的基础软件还包括：操作系统、编程语言、负载均衡、中间件、数据库或其他形式的存储等。在第一个问题中提到了几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。 最后，还是需要回到第一个问题，即由「网络 API 请求」所驱动的模型上来。作者回复: 不仅深得真传，还扩展了。 我看好你哦。
2019-12-251266
葛葛对于并发度还不太理解。请问有历史线上数据的情况如何计算并发度，没有的情况又如何估算呢？能否分别举例说明一下。作者回复: 我觉得这个会是比较简单直接的过程，所以就没有细写。逻辑如下： 1. 统计某时段的当前在线用户数； 2. 统计同一时段的操作某个功能的用户数； 3. 把所有功能操作的用户数都统计出来； 4. 将统计出来的用户数除以在线用户数就知道并发度了。
2020-01-17826
律飛问题一，如何理解“服务端的并发能力”这一描述。对于web项目而言，服务端是整个项目的关键，是咽喉要道，因此也是性能测试的重点。测试目的当然是要摸清这个要道能同时走多少人（注意这里的人不是在线用户数并发用户数，而是服务器能处理的事务），因此TPS最能描述服务端的并发能力。虽然老师一直强调压力机并发线程数不是关键，但是公式表明其与TPS、响应时间有着不可分割的联系，还需要好好体会并运用。很期待基准测试以及如何判断响应时间、TPS合理的后续讲解。 问题二，为什么不提倡使用“绝对并发”和“相对并发”的概念呢？老师讲得很清楚了，这两个概念对于我们关心的性能并没有太多的帮助，反而让人有点无从使用。在线人数，并发数，并发度简洁明了，很好理解，有利于沟通，是性能测试必备指标之一。 问题三，为什么不推荐用 CPU 来计算并发数？并发数是业务逻辑层面的，而CPU只是众多软硬件环节中的一环，即使可以借鉴，肯定也是很粗略的估计，在实践中使用价值不大，没有推广使用的必要。作者回复: 这个理解太正确了。比我写的好。
2019-12-25324
月亮和六便士老师，我们一般根据日志可以拿到在线用户数，但是并发度是百分之一还是百分之十这是全靠拍脑袋算的吗？作者回复: 通过统计每秒的业务请求数以及比例就可以知道并发度了呀。 可不能把脑袋拍坏了。
2019-12-25138
凯老师，看一下以下的推导是不是正确 对公式TPS计算公式总结： TPS就是单位时间处理事务的数量， server TPS = △事务数 / △t = 线程数 * 单个线程的事务数 / △t JMeter上给的时间是单个事务的平均时间作者回复: 对的。
2020-05-206
JK高老师您好，仍有些疑问冒昧咨询。 某项目进行接口压测，提出需满足并发800且响应时间<5秒，当时的场景设置就直接发起800线程进行负载，结果出现大量超时异常。 学习本节后，将TPS概念投射进来。假如使用TPS理解衡量并发能力的话，原文中的并发800是否等价于800TPS吗？ 参照文中例子，指服务器的TPS是100，线程TPS是20，因此推算出压测只需要发起5个线程进行负载即可。 切换到开头的例子，是否可理解服务器的期望TPS是800，而单个线程TPS是0.5（接口调用的rt是2000ms），按此验算的话压测需要发起1600线程负载才能达到原定TPS（0.5*1600=800？）。而1600个线程是否等价于N个线程*循环M次呢？作者回复: 理解的有问题哦。 “学习本节后，将TPS概念投射进来。假如使用TPS理解衡量并发能力的话，原文中的并发800是否等价于800TPS吗？” 答：显然不是的，你如果用压力线程800的话，就得看响应时间是多少、TPS是多少，这个压力线程数显然不是TPS。 ”参照文中例子，指服务器的TPS是100，线程TPS是20，因此推算出压测只需要发起5个线程进行负载即可“ 答：这个理解的对。 ”切换到开头的例子，是否可理解服务器的期望TPS是800，而单个线程TPS是0.5（接口调用的rt是2000ms），按此验算的话压测需要发起1600线程负载才能达到原定TPS（0.5*1600=800？）。而1600个线程是否等价于N个线程*循环M次呢“ 答：如果接口调用的响应时间是2s，那显然一个线程的TPS就是0.5。假设响应时间不会随着线程的增加而增加，那你就需要1600个线程才能达到800tps的要求。而这1600个压力线程，显然不能等价于N个线程*循环M次，而是1600个压力线程才对。
2020-03-09116
hou‘’这时对 Server 来说，它处理的就是 100TPS，平均响应时间是 50ms。50ms 就是根据 1000ms/20TPS 得来的（请注意，这里说的平均响应时间会在一个区间内浮动，但只要 TPS 不变，这个平均响应时间就不会变）。‘’ 这里不太明白一点，tps是每秒完成的事物数，还是每秒在处理的事物数，还是每秒请求的事物数？ 如果按照引用文中所示，1000/20=50的响应时间，我理解为20tps为每秒完成的事物数。 在前一章例子中，在线10000人，并发度5%，算出的500个tps，又让我感觉tps是指每秒的事物并发请求数。 在我的理解中，请求数和完成请求数是不同的作者回复: TPS是完成的事务数。 你说的20tps是一个线程的。 你后面的这句话，里面有好几个概念，我们简化一下：500tps就是并发数。这样是不是简单些？ 我这里写到的都是有请求有响应的才叫一个T，只请求不响应，那是半个T。
2020-02-296
顺利服务端线程的工作情况图在哪里看呢老师？linux服务器上还是jmeter有监控插件作者回复: java的可以用jvisuamvm之类的工具看。
2020-01-2126
柚子老师，我有个问题想问下，如果只知道在线用户数，不知道并发度和相应时间，怎么计算并发用户呢？作者回复: 没法计算，只能蒙了。
2020-04-145- 秋刀鱼滋味就是说算好并发度就不需要设置思考时间之类的了吗
作者回复: 不需要。
2020-03-0945
