用力过猛，把服务压挂了？

 背景   

        在刚开始进行压测的时候，我也不知道需要提前分析下压测的QPS目标，也不知道说第一步压测的预估值是多少，结果一下子干上去，就把测试环境的服务给整挂了，然后就迎来了一大波的投诉（好惨呐）

    后来慢慢的学习摸索到了，进行压测要有对应的压测计划，压测计划内必不可少的有「目标QPS」、「梯度施压详细计划」等信息。

     以下为个人压测执行总结，仅供参考～

「容量评估」目标QPS计算

    那么在进行「容量评估」压测时，我们是如何计算压测的QPS目标的呢？关于设置如何制定合理的压测QPS，我这边也简单的阐述下：

    在进行压测时，目标QPS来来源于真实环境的QPS，我们会以线上N倍QPS max进行压测，在当前服务流量的基础上，逐步施压到N倍QPS来探查过程中的性能瓶颈，计算过程如下：

     * N 需要根据公司业务的特性进行制定，一般核心 业务 链路的N是3

    案例：

• xx公司根据业务特性要求服务能够承载3倍QPS
• 真实环境的接口A的QPS max=6000、RT=30ms
• 真实环境的资源配置为6个pod

    那么测试环境进行压测的目标计算过程：资源配置为1个pod，则对应的接口A的QPS max=1000，那么3倍QPS目标=3*1000=3000

「施压」并发数计算

    由于我使用的是阿里云的PTS压测平台，所以需要通过不断提高并发数来对服务进行施压，从而到达目标QPS。所以在进行压测前需要指定详细的压测执行计划，明确到每一轮预计的并发数、预估的目标QPS。

    计算公式：并发数=QPS*平均响应时间

案例：

    假设QPS目标为3000，RT耗时30ms，那么对应的并发数=3000*0.03=90

「压测策略」梯度式压测

    在做压力测试的时候，一般都是按照梯度施压的方式去逐步增加并发用户数，而不是在没有预估的情况下，一次加几万个用户，导致服务或者数据库直接被打挂，造成大面积的请求失败。

案例：

    已经知道目标QPS 3000，预估并发数90，那么可以从1/3并发（30）开始施压

轮次	并发数	预估QPS
1	30	1000
2	45	1500
3	60	2000
4	75	2500
5	90	3000

    1/3只是个参考值，也可以从更低10或者其他值开始进行试压，但是第一轮压测并发数不建议超过「预估并发数」。

    当然，施压的用户并发数也不一定准确，可能在资源充足的情况下，并发数30也可以直接到达目标QPS，在心里没底不知道施压多少的时候可以用这种方式来计算首次施压的并发数。

凡事先讨好自己

至于别人

分交情

看心情

做人就要酷一点