对于一个大而全的系统来说，做压测确实是挺难的，不过对于直播这种产品、系统相对独立的服务来说，做压测的可行度和意义较高。
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（https://github.com/wg/wrk）工具，开始看到其有pipeline功能，我以为是并行请求的一个特性，实际上只是http pipeline的功能，在一个连接中发送多个请求，和自己预想的不太一样。
不过这个工具扩展性还是不错的，需要lua语言支持，可以扩充更多的功能，比如delay功能，response功能。（推荐阅读：直播系统性能优化实战及思考）
源自公众号 虞大胆的叽叽喳喳