05丨指标关系：你知道并发用户数应该怎么算吗？

精选留言(17)

• 

  @zzw

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

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

  2019-12-25

   4

   11
• 

  律飛

  问题一，如何理解“服务端的并发能力”这一描述。对于web项目而言，服务端是整个项目的关键，是咽喉要道，因此也是性能测试的重点。测试目的当然是要摸清这个要道能同时走多少人（注意这里的人不是在线用户数并发用户数，而是服务器能处理的事务），因此TPS最能描述服务端的并发能力。虽然老师一直强调压力机并发线程数不是关键，但是公式表明其与TPS、响应时间有着不可分割的联系，还需要好好体会并运用。很期待基准测试以及如何判断响应时间、TPS合理的后续讲解。
  问题二，为什么不提倡使用“绝对并发”和“相对并发”的概念呢？老师讲得很清楚了，这两个概念对于我们关心的性能并没有太多的帮助，反而让人有点无从使用。在线人数，并发数，并发度简洁明了，很好理解，有利于沟通，是性能测试必备指标之一。
  问题三，为什么不推荐用 CPU 来计算并发数？并发数是业务逻辑层面的，而CPU只是众多软硬件环节中的一环，即使可以借鉴，肯定也是很粗略的估计，在实践中使用价值不大，没有推广使用的必要。

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

  2019-12-25

  

   2
• 

  月亮和六便士

  老师，我们一般根据日志可以拿到在线用户数，但是并发度是百分之一还是百分之十这是全靠拍脑袋算的吗？

  作者回复: 通过统计每秒的业务请求数以及比例就可以知道并发度了呀。
  可不能把脑袋拍坏了。

  2019-12-25

   2

   1
• 

  💋💋💋

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

  作者回复: 你这个结果看起来是不太对。要不你加我微信发详细点的数据我看看：Zee_7D
  
  第二次回复：根据这位同学的反馈，他加了定时器。这样就导致了压力工具中真正的并发线程数不再是设置的线程数了。
  吓了我一跳，我还以为久经杀场的最简单的计算逻辑出了大漏洞呢。哈哈。

  2019-12-27

   1

  
• 

  心怡

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

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

  2019-12-26

  

  
• 

  吴小喵

  TPS计算公式中的压力机线程数是指压力机并发线程数吧，而不是开了几个线程的数量

  作者回复: 在另一条留言中已经回复。

  2019-12-26

  

  
• 

  吴小喵

  第二个例子中的压力机线程数为什么是10啊，之前不是说是5吗

  作者回复: 10个是压力机上的线程数。
  
  前面说的5是服务端开的tomcat线程数。

  2019-12-26

  

  
• 

  Eight Baby

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

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

  2019-12-25

   2

  
• 

  悦霖

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

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

  2019-12-25

  

  
• 

  余

  还是不太明白，"通过统计每秒的业务请求数以及比例。。。"，这个比例是怎么得到的呢？

  作者回复: 后续篇幅中有详细的推演过程。😀
  我已经为你这样的问题做好了准备。

  2019-12-25

  

  
• 

  无心

  1000ms是怎么来的

  作者回复: tps中的s就是秒呀。

  2019-12-25

  

  
• 

  奔跑的栗子

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

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

  2019-12-25

  

  
• 

  简凡

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

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

  2019-12-25

   1

  
• 

  kangny

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

  作者回复: 把TPS调到最高就好。压力大，响应时间长了，tps下降了，那服务端的处理能力明显是下降了嘛。
  不是用TPS来定义并发用户线程数，这两者的关联关系，只有在执行过程中确定，没有谁定义谁。

  2019-12-25

  

  
• 

  @权志宇

  我认为绝对并会有一种误解的测试案例，就是指定时间堆积大量线程测试瞬时流量高峰场景。这个不足以证明系统实际并发能力

  作者回复: 这也不是绝对并发的意思。
  而是秒杀场景。

  2019-12-25

  

  
• 

  @权志宇

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

  作者回复: 阔以滴。

  2019-12-25

  

  
• 

  大拇哥

  刷新了认知，等待后续的干货

  2019-12-25

  

  