💠

💠 2023-10-09 19:16

基准测试

目标

1 挖掘系统瓶颈点，优化系统性能

尤其对新系统上线，缺乏性能基线数据，此时压测一般没有明确的qps/rt等指标，而是通过不断施压，不断逼近系统的极限，从而暴露问题，修复问题。 2 建立性能基线

主要是为了收集系统当前的最大性能指标，一般会根据业务特点，先确定对rt和错误率的容忍度，然后通过压测推算出能够支持的最大qps, 并发量等。

同时可以结合性能指标和监控数据，来建立合理的预警机制，设立系统水位报警项，限流阈值，弹性策略等。

量化系统能力/SLA等 （比如在竞标中引用）。 3 性能回归

对于已上线系统，或者性能需求明确的系统，可以根据线上实际的运行情况，确定系统需要支撑的qps/rt, 然后在涉及性能影响前做回归校验，确保性能满足预期。 4 系统稳定性

更侧重在一定压力的情况下，系统是否能长时间稳定持续的提供SLA保障。

一般可以考虑将压力设定到业务峰值的80%，持续施压。 5 网络/线路延迟稳定性等

在一些特殊的业务场合，对延迟的容忍度极小，比如DNS解析，CDN服务，多人实时在线游戏，高频交易等等，需要网络质量，尤其是不同线路（电信/联通/教育网/…）间的差异。

测试对象

  • 后端
    • 单api
    • 单业务逻辑场景
  • 前端
    • 单request
    • 单操作
    • 单页
    • 整体页面平均情况

准备

关注指标项

QPS TPS PV RT CPU占用率 CPU Load 逻辑核心数1.2以下? 内存占用率 出向和入向流量

client

  • 前端框架基准测试
    • TTI（Time to Interactive）：让一个页面变得可交互需要多长时间。
    • 速度指数（Speed Index）：页面处理内容的速度，分数越低也好。
    • FCP（First Contentful Paint）：从导航一个页面到浏览器开始渲染 DOM 第一个字节的时间。
    • FCI（First CPU Idle）：页面达到最小化可交互的时间（不需要等到页面上的所有元素都可交互，只要可以对大部分用户输入做出响应即可）。
    • FMP（First Meaningful Paint）：用户感知到页面主要内容可见的时间。
    • 预估的输入延迟（Estimated Input Latency）。

server

  • PV
  • QPS
  • RT
  • 成功率
  • cpu usage
  • load
    • 最大用户同时在线数 （用户登录系统，一般不需要额外压测，除非业务场景特殊）。
  • mem
  • jvm/fullGC
  • 连接数(netstat)
  • disk io (iostat / iotop)

测试方式

  1. 寻找一个初步的并发数, 执行测试, 观察记录以上指标值
  2. 调整并发数,观察记录指标值, 观察不同并发数导致的数据变化规律
  3. 依据以上多份数据找到并发数增长情况下 哪些指标值出现明显瓶颈,对症分析和优化

注意:

  • 首次确认的并发数可以通过预估 以及 历史项目的经验值
  • 输入为 并发数 总请求量, 输出为观测指标值, 相同的输入情况需要多次测量降低误差
  • 测试时需要考虑每次测试的环境差异( 数据库缓存, 应用缓存, CPU负载波动, )

测试环境准备

硬件配置信息: CPU,内存,硬盘,网络 软件配置情况: 集群节点数, 集群策略, 缓存策略,网络拓扑

Clickhouse 性能瓶颈

Zookeeper在Clickhouse中的应用
ReplicatedMergeTree 引擎

需要协调分布式 DDL 的执行(once语义) - 单个节点A收到用户的分布式DDL指令 - 节点A校验 分布式DDL 请求合法性, 在ZK 任务队列中创建Znode 上传 DDL LogEntry,节点下创建 finish和 active节点 - 集群内所有节点消费 LogEntry队列, 将节点自身注册到active上,将处理结果写入finish节点 - 节点A 轮询ZK检查 finish是否全部节点都完成. 以及active节点是否有超时现象.

ReplicatedMergeTree表主备节点之间的状态同步 - 重度依赖ZK

CK架构是 每个节点都是平等的, 没有master worker的这种角色差异. 也导致了数据的协调和管理工作落在了CK上, 用户发出的指令可以落在任意的节点上执行, 默认命令都是单机执行,需要加 on cluster才会触发集群内所有节点执行对应的指令.

  1. 数据工具体系项目 产品介入, 标准开发流程, 全局视图