【性能测试入门教程】你真的理解并发数吗

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/beihexiazai/article/details/89713794

从事测试行业的朋友,或多或少都知道并发数的概念。在计算机领域里,并发数是指同时访问服务器站点的连接数。

在实际工作中,经常发现很多人对并发数有误解。

比如领导说我们系统有10w活跃用户,所以系统必须要支持10w并发;

比如压测报告里写某个接口支持50并发,客户就会反问难道系统只支持50用户同时访问?性能是不是太差了!

问出上面问题的人,大多数都存在一个理解上的误区,认为性能测试中的并发数=并发用户数,其实事情没有这么单。

我个人从事了多年的性能测试工作,我来说一下我对并发数的一些理解。

并发其实有两种:用户端并发和服务端并发

具体有什么区别呢?给大家举一个例子。

一般来说,抢购和秒杀服务是并发数最高的项目类型,比如某网站8点开始抢购某商品,抢购系统部署在北京的某个机房里。所有的用户都是通过浏览器或者APP来进行商品的抢购。在开始抢购之前,已经有10w个用户预约了该商品,所以我们可以预测到,8点的时候会有将近10w人(极端情况下)同时去进行抢购。那么这个时候,意味着10w个客户端同时开始处理用户的抢购操作。

客户端(APP或浏览器)往往是需要先进行一些逻辑处理,才会把抢购请求发送到服务端。但是客户端运行设备和环境是不同的。

有人用的是iPhone XS Max;

有人用的是金立双卡双待语音王;

有人用的是最新款的MacBook Pro;

有人用的是小霸王学习机。

不同的客户端环境,运行速度是有很大差别的,所以即便有10w人同时在8点开始点击抢购,等待客户端向服务端发起抢购请求时,同一时刻发出的请求已经不足10w了,可能只剩下9w了。

大家都知道不能让自己的孩子输在起跑线上,但是在这个阶段,有一批拥有更好设备的用户请求已经发送出去了,另外一批低端设备用户在起跑线上已经输了。

然而残酷的竞争才刚刚开始,客户端把请求发送出去后,需要通过漫长的网络传输到位于北京机房的服务器上。

这个时候更大的差异出现了。参加抢购的用户分布的全国各地,网络制式也各有不同,4G/3G、联通/电信宽带,50M/100M的带宽,比起客户端设备之间几毫秒的差距,不同环境下网络的延迟差距可能有几十毫秒。

在黑龙江漠河的小镇上,铁柱正盘着腿坐在炕上,焦急的等待着手机上显示的排队结果;

在祖国最南的西沙群岛,渔民阿祖在自己的渔船上看着手机上页面一直在转圈圈,而此时手机信号只有2格;

同样的,在北京北五环外的回龙观,在不到十平米自如次卧里,小王看到了电脑屏幕上出现了支付成功页面,此时的他满眼都是欣喜,这一刻,他感觉自己是天选之子。

一场抢购盛宴落下帷幕了,在这个过程中有很多细节值得我们思索。在服务端来看,因为客户端设备的差异和网络的延迟,10w个并发请求,并不是同时到达服务端的,而且会在一段时间内陆续到达。假设在100ms内全部到达,并且认为同一毫秒到达服务器的请求属于同一时刻,那么服务端同一时刻处理的并发请求,也就1000个左右。

从上面的例子里大家也都看出来了,用户端并发和服务端并发是有着巨大的差异的,用户端并发>服务端并发。具体多少倍的差异无法计算,因为用户端的环境是无法预估的。但是可以肯定的是,这个差距肯定是巨大的。

从另外一个角度来看,在上述的例子中,假如网络延迟为0,那么用户端有多少并发同时请求,在服务端同时接受到的几乎就是多少并发。在这种情况下,用户端并发=服务端并发

所以日常在做性能测试过程中,为了降低网络延迟,客户端压力机和项目服务器都在同一个局域网中,一般都在同一个机房,这样网络的延迟是<1ms的。几乎可以认为是没有延迟的,在客户端压测工具上设置了50并发,那么在服务端也是50并发。

如果上面讲的你都可以理解,那么文章开头那两个问题就有答案了。压测时系统支持50并发,是指服务端支持50并发,并不是只支持50个用户同时去访问。而是远远大于50个用户。

这也从另一个方面说明了一个问题,并发数是一个重要的指标,但是在性能测试中,不需要过分关注并发数的多少,而更应该关注处理的业务量(即TPS),只要系统的TPS足够高,处理业务的时间足够短,哪怕同一时刻来再多的并发请求(只要不超过软硬件限制),我服务器也能给你安排的明明白白的。

展开阅读全文

没有更多推荐了,返回首页