压测应该怎么做

如果你对此话题感兴趣，建议先看下《 解决复杂问题的第一步是隔离 》这篇文章。

对于一个大而全的系统来说，做压测确实是挺难的，不过对于直播这种产品、系统相对独立的服务来说，做压测的可行度和意义较高。

1：目标

在做压测之前，先思考目标：

衡量单机支撑能力，第一反应就是需要多少台服务器，其实对于一个系统来说，除了web服务器，更多的还要考虑资源，比如redis、mysql、流量等等。

如果考虑单机支撑能力，主要看峰值qps和负载的关系，在可控的负载下，看机器能支持多少qps，不过如果测试单接口，这个qps衡量意义就有折扣。

集群的支撑能力，通过压测想预测整个系统的支撑能力，实际上是走错路了，通过 正确 的压测也许能找出瓶颈点。

压测可以和容量预估同步考虑，根据历史数据找出dau、在线用户数、峰值qps与资源的关系，比如slb的峰值流量；峰值接口qps；mysql峰值慢查询；redis连接峰值和qps峰值。

但这个预估很难找出规律，比如一个秒杀活动，一场直播，带来的请求分布完全不一样，如果压测要模拟这些行为，那就更难了。

关键词：容量增长预估，峰值指标，资源数量。

2：如何部署一个好的测试系统

为了压测，必须部署一套好的环境。

隔离，很简单，提供的环境不要和线上服务有任何瓜葛，就算压垮了，也不会影响服务。

对于直播系统来说，除了主库不能隔离，其他都能；虽然可以构建一套新库（包括主从），但如何将线上库数据同步过去，本身就很有挑战。

仿真，提供的环境必须和线上服务是差不多的，否则就不真实了。

这次深有体验，QA用的mysql5.6，而压测环境用的5.7，就出现了问题。

不真实就可能出现差异，导致判断失误，是否能够快速提供压测环境，也是衡量系统架构成熟的一个标准。

成本，其实这点非常重要，不过如果整个系统设计的好，采购按量付费的资源相对成本可控。

3：压测模型

外网压，还是内网压，有些压测工具每次连接会重新进行dns查询，再加上tcp握手，最终的压测指标会非常不好，所以使用内网压测相对靠谱一点。

模拟数据，压测的数据要广，比如不能就使用一个session会话用户测试，必须使用尽可能多的session用户压测，这需要应用层协助解决。

另外压测的数据不要全是缓存的数据，这也是测试用户要分布广的原因之一，甚至在特定测试条件下，完全不使用缓存。

理解压测工具本身的局限性，比如压测工具可能会开多个线程，压测方机器性能不好的话，直接影响测试出的结果数据。

另外上面也说了，压测工具会走完整的网络连接、dns解析，这和真实app请求情况是不一致的。

单接口压，单接口压测主要是衡量单机qps，有的时候开多个线程，每个线程并发n多连接，并持续m秒，这种情况下，cpu会满负载运行，负载可能会飙到50以上，这个时候不能说单机支撑能力不足，实际上现实不会出现这种情况，这也是压测比较难的一方面

瀑布式压，压测的时候尽量模拟真实行为，对于直播来说，直播间的行为可以合并汇总，取得每个接口的峰值qps（比实际情况高），然后对接口做一个访问比例的排列，压测的时候可以按照这个比例请求，这样相对真实一点。

比如一个线程模拟一个用户的行为，整个流程将所有接口按照比列访问一遍。多个线程持续这个行为的话，模型相对是可信的，但如果持续请求，实际上和线上情况是不一样的，但delay多少呢？

4：压测工具

我以前用ab进行压测，同事用的wrk工具，开始看到其有pipeline功能，我以为是并行请求的一个特性，实际上只是http pipeline的功能，在一个连接中发送多个请求，和自己预想的不太一样。and

不过这个工具扩展性还是不错的，需要lua语言支持，可以扩充更多的功能，比如delay功能，response功能。