性能测试并发量评估新思考
相信很多人在第一次做压力测试的时候，对并发用户数的选择一直有很多的疑惑，那么行业内有一些比较通用的并发量的计算方法，但是这些方法在如今微服务的架构下多少会有一些不适合，下面的文章我们对这些问题进行一些讨论，说一说我的思考。
传统的并发量的计算方法
下面介绍一些行业内的通用的计算方法，但是这些方法也不是绝对正确的方法，这些仅仅是压力测试并发用户数的一种计算方法，但是最后是不是n的并发就可以支持m级别的用户也是由被测系统逻辑复杂的决定的，可以用如下的一种方法确定初始开发压力测试的并发用户数。
计算方法一
-
1）平均并发用户数为 C = nL/T
-
2）并发用户数峰值 C‘ = C + 三次根号C
其中C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度，C’是并发用户数峰值。
例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。
平均并发用户数为：C = 400*4/8 = 200 并发用户数峰值为：C‘ = 243
例2， 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。
则一个月最后一周的平均并发用户数为（朝九晚五）： n = 170000*0.5*0.7/5 = 11900； C= 11900*5/60/8 = 124 C'=129
计算方法二
对绝大多数场景，我们用（用户总量/统计时间）影响因子（一般为3）来进行估算并发量。 比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为5000080%/（36060）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大。
C=12
计算方法三
比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：1000w80%/(93600)=246.92个/s,取经验因子3，则并发量应为：
C=246.92*3=740
计算方法四
C = 系统最大在线用户数的8%到12%
计算方法五
C=(Think time + 1)*TPS
微服务下的并发估算
如上的并发估算无论是机遇用户数量的计算、还是机遇访问行为的计算都是基终端用户的访问模型进行的一些计算。这些计算方法在当前微服务的架构下有可能有些并不是十分准确，假设有如下一个接口的访问模式。
一个页面包含了4个区域，这四个区域分布调用API A、API B、API C和API D，API A会调用API X，API B和API C会调用API Z，API D会调用API Y。那么假设我们用上面的任何一种方法计算出来该页面的并发量是500，那么从如上示意图中我们可以看出，如果我们用任意一种压力测试工具测试对应接口是500并发，并不对。因为微服务之间的调用，有一些服务有可能会出现访问了激增的情况，这个激增有可能远远大于我们原始的计算评估值。
API Z 因为有三个调用，并且这三个调用都是来自页面的访问，因此Z的并发量应该从1500的并发量作为基准开始进行压力测试，这样评估出来结果才有参考价值。因此微服务下的每个服务的并发量，应该在服务治理后，梳理清楚微服务的调用关系，然后从访问页面的并发量的估算开始，然后逐步分析每一个微服务的最大并发量，在进行计算后作为压力测试的并发起始点，开始进行压力测试。
