性能压测实践

以下是我们在做IM业务性能压测的过程中，积累的一些点和经验。

环境准备

压测工具的选择

目前我们用的是Apache JMeter - Apache JMeter™[1]，其他常用的工具还有：

•Locust - A modern load testing framework[2]

•ab - Apache HTTP server benchmarking tool - Apache HTTP Server Version 2.4[3]

•Tsung[4]

至于使用何种压测工具，可以根据团队习惯的编程语言以及工具对业务场景的支持度和覆盖度来选择。比如熟悉erlang的话可能会偏向于Tsung，或者选择的工具可以满足大部分业务场景的压测需求。

对于已选择的工具，需要了解其配置参数和使用的一些限制等，在必要时更改一些参数，避免由于参数配置不当造成压测工具存在性能问题，进而影响最后的压测数据。

比如对于JMeter来说，如果要做单机压测，那么并发数不能超过1000，当然这也跟部署JMeter的物理机配置有关，但至少会给我们一个大概的理论值，让我们清楚如果要做接近或者大于这个数的并发，就要考虑分布式压测了。

压测环境的网络问题

最好将服务部署在同一机房的多台机器，且JMeter也部署在同一机房，避免网络消耗对压测数据产生影响。如果不能部署在同一机房，那么也要尽可能部署在同一网段，甚至如果跨网段部署，要了解是否有带宽限速等。

压测环境的隔离

应该保证压测环境是一套单独的环境，不与开发环境、测试环境有任何的交集，包括：

•服务的隔离，要单独部署服务

•数据的隔离，账号数据不与测试环境共用

•中间件的隔离，比如Kafka topic要单独申请一套，避免压测环境产生的消息与测试环境的消息走一个通道

注：缓存和数据库可以不用隔离，因为已经做了数据上的隔离，那么即使存到同一个库，相互之间也不会影响

进行压测

1、需要先定义出系统的SLA（service-level agreement，即服务等级协议），它是衡量系统在提供服务时要满足的一系列指标。

拿IM业务来说，即我们在提供服务时，需要满足以下这些指标：

•接口请求耗时在200ms以内

•消息从发送到对方成功接收在3s以内

•限定服务所用的资源，比如CPU数量在30个

根据定义好的SLA去进行压测

2、如果系统有使用中间件，最好了解一下中间件的配置参数和能达到的QPS，以便出现中间件是瓶颈的情况，可以调整配置参数来提升其性能。

3、需要从主分支上切出一个压测分支，便于在其上进行代码改动且不影响其他分支。

4、排除对外部系统的依赖，如果服务中有对外部系统的调用，那么需要在代码上注释掉这些调用，避免外部系统可能产生的瓶颈制约本系统的性能。

5、对于压测结果数据的产出，如果是常规的性能数据及报表可以直接由工具生成，对于业务相关的一些性能数据，需要依靠在程序中打点来跟踪整个链路中各节点之间的耗时，具体来说就是添加日志记录时间，通过程序去分析日志，计算出耗时。

注：

常规的性能数据，比如接口的QPS，95分位、99分位的响应耗时

业务相关的性能数据，拿IM发送消息举例，是从消息发出到对方成功接收到所用的时间

6、对系统做空接口的压测，并生成压测数据，了解系统在无任何业务逻辑的情况下性能数据大概在多少范围。

7、在正式做压测之前，需要准备好压测的业务数据，比如用户账号数据。如果压测环境做了存储隔离，那么需要从测试／线上库将数据导入到压测库；如果没做存储隔离，那么需要拿程序生成数据。

8、在压测的过程中，需要关注并记录服务占用的CPU、Memory等资源的使用率，并尽量使其中一项资源被占满，才能说明已经到了系统的负载上限，也即系统最高能承受的QPS。如果服务分多级，比如接口服务会调用MQ异步处理数据，那么要在压测时不断调整各级组件的配比，找出系统能承受最高QPS时的各组件配比。

9、关注存储的性能瓶颈。一般来说，存储的性能瓶颈会在系统架构时去解决，但要注意，在压测时不要让存储的性能瓶颈影响压测数据。假如IM业务中有写入Redis的用户未读消息数据（使用zset结构），那么要在压测时定期清理zset的数据，不要因为zset长度过长，导致操作Redis耗时变长而影响压测数据。

10、由于服务分布部署在多台物理机上，需要注意机器之间NTP（Network Time Protocol）时钟同步可能会对打点的数据造成影响，如果延迟在几十毫秒左右，应该影响不大。

结果产出

在满足SLA的前提下，压测报告中需要体现以下数据：

•部署服务的机器配置（虚拟机／物理机），包括CPU核数、内存大小、网络带宽等

•服务部署的实例数，如果有多级组件，需要列出各组件的实例数，以及单个实例所占用的资源数

•压测方式，比如用多少个并发，持续压了多长时间，对哪些业务场景进行压测

•常规的性能数据，包括QPS，95分位、99分位的响应耗时及平均响应耗时

•业务相关的性能数据，比如IM发送消息，从发送到对方成功接收到所用的时间

•压测期间系统各组件占用的资源利用率（CPU、Memory等）

然后根据压测数据预估系统线上QPS达到多少的情况下，服务需要配置多少资源来支撑。

总结

做性能压测是为了让我们对线上系统的压力和峰值做到心中有数，对于可预见的流量峰值提前做好扩容准备，以及从容的应对未来线上流量的持续增长。

引用链接

[1] Apache JMeter - Apache JMeter™: https://jmeter.apache.org/

[2] Locust - A modern load testing framework: https://locust.io/

[3] ab - Apache HTTP server benchmarking tool - Apache HTTP Server Version 2.4: https://httpd.apache.org/docs/2.4/programs/ab.html

[4] Tsung: http://tsung.erlang-projects.org/