压测的一些思考

压测的目的，在于保证系统达到某个量级的情况下不会死掉，在岗位划分上，专门做这件事的人可以被称作 性能工程师 ， 主要的工作就是做压测、性能分析、性能优化、服务可靠性提升。我们做压测，同样要向这些目标看齐，把整个系统的抗压能力提升起来。

整体来看，性能是一个系统工程，需要整个体系做配合，因此，性能可以提升到很高的高度，作为一个十分重要的事。当然，对于具体模块的性能优化，也可以是一个独立的模块，例如，对于部分 http 请求的性能优化、对于数据合并方式的性能优化。

站在类架构的角度考虑问题，可以考虑这些问题：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
1. 高可用
    - 分布式集群
    - 负载均衡
    - 探活
    - 容错/限流/熔断
    - 监控/告警/链路追踪
2. 高可扩展
    - 无状态
    - 模块化
    - 生产/消费模型
3. 高性能
    - 异步
        - 队列优化
        - 弹性优化
    - 多线程
        - 线程池优化
    - 数据/算法优化
        - 合适的数据结构
        - 数据压缩
    - 基础设施优化
        - 存储优化
        - 网络优化
        - 基础组件优化
    - 缓存优化
        - CDN优化
        - PWA优化
        - 数据库缓存优化

上面罗列的这些，只是一些可优化的方向，对于具体模块的优化，需要有针对性的分析。

从整个性能测试的流程上来看，可以分成以下部分：

  1. 性能需求指标
    要有清晰明确的压测目标，目标需要根据场景进行划分。

  2. 压测场景与模型
    要有明确的模型知道真实业务场景如何，并据此构建性能测试时的模型。一般来说，可以有： ① 基准场景 ② 容量场景 ③ 稳定性场景 ④ 异常场景。我们当前的压测场景，主要是基于 基准场景 和 容量场景 两类做具体的压测。

  3. 压测环境准备
    需要尽量保证和线上近乎一样的数据量，近乎一样的基础设施。

  4. 压测数据准备
    需要尽量保证和线上近乎一样的数据。压测脚本尽量和真实业务场景一致。

  5. 压测实施与监控
    完善的监控体系，最好有压测时的监控大盘，主要的目的是能近实时地发现性能瓶颈点。

  6. 压测数据收集
    指标有哪些，如何收集。常见的指标，类似于： ① TPS 平均值 ② TPS 95分位值 ③ 系统资源使用(CPU、MEM、load average、net、disk iops) ④ 中间件状态(mongo、redis、kafka、db)

  7. 性能分析与证据收集

  8. 压测报告与优化方案

  9. 优化实施控制
    需要建立优化的反馈机制，保证优化方案得到落实，并且优化结果证明优化确实有效。

整个性能测试的体系，可以参考：

要关注的内容：
资源层面：

  1. 网关的网络流量
  2. ingress的网络流量
  3. node的网络情况
  4. node的socket连接情况
  5. node的CPU使用情况
  6. node的mem使用情况
  7. pod的网络情况
  8. pod的socket连接情况
  9. pod的cpu使用情况
  10. pod的mem使用情况

中间件层面：

  1. mongodb的cpu和内存消耗
  2. mongodb的平均响应时长
  3. mongodb的缓冲队列
  4. mongodb的iops
  5. mongodb的ops
  6. redis的平均响应时间
  7. redis的慢响应
  8. redis的qps
  9. redis的内存耗用情况
  10. redis的命中率等
  11. pg的平均响应时间
  12. pg的慢响应
  13. pg的qps
  14. pg的内存使用情况
  15. kafka的情况？[待补充]

业务指标层面：

  1. api 的接口响应时长
  2. api 的错误率
  3. task 的数量
  4. task 的平均处理时长
  5. messenger的ws握手时长
  6. messenger的消息吞吐量
  7. messenger的消息送达率
  8. messenger的消息顺序性
  9. messenger的报错情况
  10. merger的消息吞吐量
  11. merger的消息平均处理时长
  12. merger的报错情况
  13. 单个文件的消息处理能力(从客户端角度)

目标：

  1. 从基础设施的角度，弄清楚一些基础基准测试。
  2. 从业务的角度，弄清楚不同量级下，我们的瓶颈将会是什么，如何证明。

执行记录：

  1. 当前 【所有】 配置情况
  2. 执行操作计划 (何时开始，何时停止)

要做的事：

  1. 对各个模块做 bench，例如，网络、磁盘、中间件，得到基准值。 各个模块要做的基准测试
  2. 对 lancer-service 的相关模块抽取出来，作为独立的压测工具，增加对每条消息的统计，增加分析查询接口。
  3. 针对需要覆盖的性能测试场景，做好数据准备。

其他的一个想法：
如何让想法得到落地，以达到真正促进业务发展的目的？ => 成为一个对性能负责的人。

一些问题：

  1. 是否需要线上全链路压测？
    没必要。压测的目的，是尽量还原真实业务场景下，为了达到既定的性能需求指标，找到性能瓶颈并优化，同时保证在既定水位线以内系统不崩溃。那么，我们只要能尽量还原真实业务场景即可，通过增加一定的冗余来解决模型偏差带来的不准确即可。线上压测有两大问题： 1. 开发成本高，人员精力分配上存在问题。2. 需要对系统掌控能力很强，几乎不能出错误，否则影响面将非常广。

要做的一些事：

  1. 梳理当前要做的压测目标，使用更专业的流程框架，赶紧做出第一版压测。
  2. 建立整个性能测试过程的控制文档，将性能测试标准化。
  3. 和他人协作、交流、培训，让其他人也能很快上手性能测试。

文档直通车：

How many cares one loses when one decides not to be something but to be someone.
— Coco Chanel

性能 压测

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！