性能测试实战30讲
高楼
前HP高级性能专家,7DGroup创始人
立即订阅
3507 人已学习
课程目录
已更新 7 讲 / 共 30 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词丨“老板,之前咱TPS是100,我优化完是10000”
免费
第一模块:性能测试基础篇 (6讲)
01丨性能综述:性能测试的概念到底是什么?
02丨性能综述:TPS和响应时间之间是什么关系?
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
05丨指标关系:你知道并发用户数应该怎么算吗?
06丨倾囊相授:我毕生所学的性能分析思路都在这里了
免费
性能测试实战30讲
登录|注册

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

高楼 2019-12-25
我在性能综述的那三篇文章中,描述了各种指标,比如 TPS、RPS、QPS、HPS、CPM 等。我也强调了,我们在实际工作的时候,应该对这些概念有统一的认识。
这样的话,在使用过程中,一个团队或企业从上到下都具有同样的概念意识,就可以避免出现沟通上的偏差。
我说一个故事。
我以前接触过一个咨询项目。在我接触之前,性能测试团队一直给老板汇报着一个数据,那就是 10000TPS。并且在每个版本之后,都会出一个性能测试报告,老板一看,这个数据并没有少于 10000TPS,很好。 后来,我进去一看,他们一直提的这个 10000TPS 指的是单业务的订单,并且是最基础的订单逻辑。那么问题来了,如果混合起来会怎么样呢?于是我就让他们做个混合容量场景,显然,提容量不提混合,只说单接口的容量是不能满足生产环境要求的。
结果怎么样呢?只能测试到 6000TPS。于是我就要去跟老板解释说系统达到的指标是 6000TPS。老板就恼火了呀,同样的系统,以前报的一直是 10000TPS,现在怎么只有 6000TPS 了?不行,你们开发的这个版本肯定是有问题的。于是老板找到了研发 VP,研发 VP 找到了研发经理,研发经理找了研发组长,研发组长又找到了开发工程师,开发工程师找到了我。我说之前不是混合场景的结果,现在混合容量场景最多达到 6000TPS,你们可以自己来测。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《性能测试实战30讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(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
收起评论
17
返回
顶部