压测其实并非上线之前才进行，而是在开发之初就开始准备了。一般情况下在开发之前设计之时就应该明白哪些接口会面临高并发压力，所以在开发时就要按照能够承受高并发的标准进行开发，比如尽量减少数据库操作、采用连接池、逻辑尽量简单等等。如果逻辑确实复杂，就要采用异步处理来解决。 **压测的目的** 搞懂为什么要压测，这样在压测的时候才不会事倍功半，毕竟压测一次的成本还是蛮高的。压测其实有两个目的，一是测试应用在高并发情况下是否会报错，进程是否会挂掉；二是测试应用的抗压能力，预估应用的承载能力，为运维同学提供扩容的依据。 第一点很好理解，做好这一点就可以保证上线之后不出问题了。解释下第二点，我们都知道就是架构设计的再优秀，代码写的再好，应对高并发单实例始终是有限的。所以通常是在满足第一点的前提下，再根据可能到来的高并发压力来计算需要多少实例来承载，而这就需要我们压出极限。 **第一次压测** 接口开发完成之后就可以进行第一次压测。这一次压测可以简单压一下，在本机进行就可以。压测的目的是检查代码在高并发下是否会报错。另外，编译型语言要观察是否存在内存泄漏，比如golang。 因为本机性能有限，一般来说按照100、200、300、500进程数进行压测，压到500如果没有报错就可以进行疲劳测试，观察内存占用。 **第二次压测** 一般来说是不可能在线上进行压测的，所以一般都是在仿真环境。所以这就对仿真环境提出了更高的要求。 这一次压测重点是压极限。比如说我们目标并发数2000，那么就要从500-2000开始递增的进行压测。比如第一次压500的时候就出现了一些报错，这时候就是遇到了第一个瓶颈。当解决第一个之后再继续压500，确认解决了第一个瓶颈就可以继续往上加，如此循环直到压到目标并发数2000。 **常见的瓶颈** php-fpm进程数。一般php-fpm的进程数是dynamic模式，也就是说动态调整。这种模式下无法应对瞬时的高并发情况，因为他的进程数有个逐渐增加的过程。 负载均衡限额。比如阿里云的SLB最近就增加了配额限制，免费版的实例只有5000的最大连接数，3000的CPS和1000的QPS。 应用服务器、Redis、MySQL最大连接数、CPU和内存等等。这些都是比较严重的限制，所以一定要在压测之前就搞清楚。 **如何来判断遇到了什么瓶颈。** 503 -- 服务不可用，一般是负载均衡、nginx达到限制。 502 -- Bad Gateway，通常是应用进程挂掉了，或者进程不够用处理不过来。 500 -- 应用故障，一般是应用抛出了异常没有正常响应，比如达到Redis和MySQL的瓶颈。 **一个不算常见的瓶颈** Redis带宽。阿里云的Redis是否带宽限制的大概是200M+，如果数据量比较大，在高并发情况下很容易把带宽打满。目前的解决方案有两个，一是在存入Redis之前进行数据压缩，在读取Redis之后再进行解压。二是采用pb进行存储，当然这两种方案我都还没有真正使用过，等我解决了这个瓶颈再来更新。 **一些压测压不出来的坑** 现在大多数正式的项目都是前后端分离的，所以上述说的其实都是压后端接口，而有一种情况是压根压不出来的，那就是接口调用数。作为后端开发，一定要搞清楚承受冲击的前端页面在加载的过程中会调用几个接口，调用几次。如果不搞清楚这些，在真实环境中后端服务器就可能承受比前端服务器还高的压力，从而影响之前针对压测数据做出的评估。 **后序** 前面就已经提到过了，压测一次的成本还是挺高的。在这个过程中还要需要各方配合，所以，最好是在压测之前就做好详细的计划，这样才能事半功倍。