压测其实并非上线之前才进行，而是在开发之初就开始准备了。一般情况下在开发之前设计之时就应该明白哪些接口会面临高并发压力，所以在开发时就要按照能够承受高并发的标准进行开发，比如尽量减少数据库操作、采用连接池、逻辑尽量简单等等。如果逻辑确实复杂，就要采用异步处理来解决。

压测的目的

搞懂为什么要压测，这样在压测的时候才不会事倍功半，毕竟压测一次的成本还是蛮高的。压测其实有两个目的，一是测试应用在高并发情况下是否会报错，进程是否会挂掉；二是测试应用的抗压能力，预估应用的承载能力，为运维同学提供扩容的依据。

第一点很好理解，做好这一点就可以保证上线之后不出问题了。解释下第二点，我们都知道就是架构设计的再优秀，代码写的再好，应对高并发单实例始终是有限的。所以通常是在满足第一点的前提下，再根据可能到来的高并发压力来计算需要多少实例来承载，而这就需要我们压出极限。

第一次压测

接口开发完成之后就可以进行第一次压测。这一次压测可以简单压一下，在本机进行就可以。压测的目的是检查代码在高并发下是否会报错。另外，编译型语言要观察是否存在内存泄漏，比如golang。

因为本机性能有限，一般来说按照100、200、300、500进程数进行压测，压到500如果没有报错就可以进行疲劳测试，观察内存占用。

第二次压测

一般来说是不可能在线上进行压测的，所以一般都是在仿真环境。所以这就对仿真环境提出了更高的要求，有条件的要保证仿真和线上配置一致。次之也要和线上成比例，这样可以方便后续评估计算。

这一次压测重点是压极限。需要特别要注意，这里的极限不是数据库极限，不是Redis极限，而是是指应用服务器的极限承受能力。上面已经说了，压极限是为了给运维同学提供扩容的参考，所以我们要做的是压到服务器的承受极限，看下到底能够承受多大的并发。假设现在线上是双实例8C8G，仿真双实例4C4G。

比如说我们我们压出仿真的极限承受能力是1000，那么我们就可以预估线上能够承受2000并发。比如我们预估接下来我们会迎来一次5000并发的冲击，那么运维同学就可以根据这些数据来评估出相应的扩容方案。

压测的常见步骤

比如第一次压500的时候就出现了一些报错，这时候就是遇到了第一个瓶颈。当解决第一个之后再继续压500，确认解决了第一个瓶颈就可以继续往上加，如此循环直到压到服务器极限。

在这个过程中我们会遇到很多瓶颈，冲破这一路瓶颈就像过关斩将一样。

常见的瓶颈

php-fpm进程数。一般php-fpm的进程数是dynamic模式，也就是说动态调整。这种模式下无法应对瞬时的高并发情况，因为他的进程数有个逐渐增加的过程。所以需要调整成static模式然后再根据服务器性能配置合理的进程数。

负载均衡限额。比如阿里云的SLB最近就增加了配额限制，免费版的实例只有5000的最大连接数，3000的CPS和1000的QPS。

压测机性能限制。这是一个比较容易忽略限制，所以我们在压测的过程中也要注意观察压测机的负载。如果达到这个瓶颈，就要考虑采用多机压测。

应用服务器、Redis、MySQL的最大连接数、CPU和内存等等。这些都是比较严重的限制，所以一定要在压测之前就搞清楚。

如何来判断遇到了什么瓶颈。

503 -- 服务不可用，一般是负载均衡、nginx达到限制。
502 -- Bad Gateway，通常是应用进程挂掉了，或者进程不够用处理不过来。
500 -- 应用故障，一般是应用抛出了异常没有正常响应，比如达到Redis和MySQL的瓶颈。

一个不算常见的瓶颈

Redis带宽。阿里云的Redis带宽限制大概是200M+，如果数据量比较大，在高并发情况下很容易把带宽打满。目前的解决方案有两个，一是在存入Redis之前进行数据压缩，在读取Redis之后再进行解压。二是采用pb进行存储，当然这两种方案我都还没有真正使用过，等我解决了这个瓶颈再来更新。

一些压测压不出来的坑

现在大多数正式的项目都是前后端分离的，所以上述说的其实都是压后端接口，而有一种情况是压根压不出来的，那就是接口调用数。作为后端开发，一定要搞清楚承受冲击的前端页面在加载的过程中会调用几个接口，调用几次。如果不搞清楚这些，在真实环境中后端服务器就可能承受比前端服务器还高的压力，从而影响之前针对压测数据做出的评估。针对这种情况，其实最好的方案就是在开发之时就跟前端约定好接口调用规则，在接口设计和交互上进行避免。

后序

前面就已经提到过了，压测一次的成本还是挺高的。在这个过程中还要需要各方配合，所以，最好是在压测之前就做好详细的计划，这样才能事半功倍。