测试必备技能：如何才能正确解读并发数？

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

在实际工作中，经常发现很多人对并发数有误解。比如领导说我们系统有10w活跃用户，所以系统必须要支持10w并发；比如压测报告里写某个接口支持50并发，客户就会反问难道系统只支持50用户同时访问？性能是不是太差了！

问出上面问题的人，大多数都存在一个理解上的误区，认为性能测试中的并发数 = 并发用户数，其实事情没有这么简单。我个人从事了多年的性能测试工作，我来说一下我对并发数的一些理解。并发其实有两种：用户端并发和服务端并发，具体有什么区别呢？ 给大家举一个例子。

一般来说，抢购和秒杀服务是并发数最高的项目类型，比如某网站8点开始抢购某商品，抢购系统部署在北京的某个机房里。所有的用户都是通过浏览器或者APP来进行商品的抢购。

在开始抢购之前，已经有10w个用户预约了该商品，所以我们可以预测到，8点的时候会有将近10w人（极端情况下）同时去进行抢购。那么这个时候，意味着10w个客户端同时开始处理用户的抢购操作。

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

有人用的是iPhone；

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

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

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

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

大家都知道不能让自己的孩子输在起跑线上，但是在这个阶段，有一批拥有更好设备的用户请求已经发送出去了，另外一批低端设备用户在起跑线上已经输了。然而残酷的竞争才刚刚开始，客户端把请求发送出去后，需要通过漫长的网络传输到位于北京机房的服务器上。

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

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

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

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

一场抢购盛宴落下帷幕了，在这个过程中有很多细节值得我们思索。在服务端来看，因为客户端设备的差异和网络的延迟，10w个并发请求，并不是同时到达服务端的，而且会在一段时间内陆续到达。

假设在100ms内全部到达，并且认为同一毫秒到达服务器的请求属于同一时刻，那么服务端同一时刻处理的并发请求，也就1000个左右。

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

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

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

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

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

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取