双11大促临近了，整个9月、10月份都是链路review+压测+故障演练+预案演练的节奏，压测作为验证系统性能的一种重要手段，我们对它的认知有哪些误区。
服务端压测总结系列：
疑惑
就我所在的业务来说：压测的主要目的是为了检验系统在日常或者大促的流量峰值期间能够正常运行，保证业务顺畅无线上问题。
在压测前，你需要了解：
- 一、测试环境压测通过了，生产环境是否需要压测了？
结论是：要
只要测试环境无法100%模拟生产环境，生产环境的压测就不可避免，二者之间的任何规格差异都有可能导致性能问题漏测。
- 二、单机压测达到目标QPS，集群是否还需要压测了？
结论是：要
集群的性能不等于=单机性能*机器数量，集群性能不是随着机器数量线性增长的，否则所有性能问题都可以堆机器解决了
随着系统压力增加，可能出现性能瓶颈的地方有很多：
1.服务器硬件的瓶颈
2.DB的瓶颈
3.缓存的瓶颈
4.网络(带宽)的瓶颈
......
一台机器我们可以压测到100QPS，10台机器可能到不了1000QPS，可能300QPS时DB就挂了（如果有慢SQL的话）
- 三、1个月前压测通过了，这个月还需要压测么？
结论是：需要评估
我们在决策是否要做压测之前（尤其是之前压测通过的系统），要基于以下几点：
从上次压测通过以来系统是否有变化？
1.代码是否有变化：只要是代码有变化、哪怕仅仅是加了一条日志，都需要仔细评估是否性能会受到影响（17年我所负责的系统就出现过一条日志使得接口RT飙升最终挤满线程池导致宕机的故障）
2.网络是否有变化：比如生产服务器换机房，换网络供应商、新增部署机器等等。
3.数据是否有变化：系统一段时间后数据表中数据不断增加也会导致性能问题。
- 四、压测达到预设的目标QPS了，还需要摸高么？
结论是：看你的压测目的
如果只是为了验证系统能否应对某个业务峰值压力，压测到能应对业务峰值水平即可，无需摸高。
如果是为了验证系统的性能基线，看看系统的性能极限在哪里，可以摸高-优化-摸高反复直至无可优化。
- 六、压测好几次了，代码也优化过几次了，一直不通过怎么办？
结论是：压不过就压不过，不会死人的，这个时候你需要review下你的QPS目标是不是定的过高了，和开发讨论下还有没有优化的空间，和业务讨论下这个业务是不是能降级掉，和依赖方讨论下能否对某些不重要的依赖方降级，压测只是一种手段，保证业务能够正常运行才是我们的最终目的。
以终为始，方得始终
