ThinkerQAQ

NOTE

2.2 压力测试

压力测试目标、QPS 估算与实践、容量评估和优化。

Testing & Performance创建于 更新于 约 3 分钟读完historical

这是历史学习笔记，可能存在过时或不完整的理解。

1. 什么是压力测试

  • 在性能可以接受的前提下，测试子系统或者接口可以支持的最大负载

2. 为什么需要压力测试

  • 找出子系统或者接口的瓶颈，才能进行相应的优化和扩容
  • 验证子系统或者接口是否能够支撑预估的力量

3. 如何设计压力测试计算 QPS

3.1. 估算

  • 根据吞吐量=并发度/响应时间
    • 如果是计算密集型应用，那么取决于 CPU 核数。假设 CPU 为 4C，接口响应为 100ms，100ms 全部用于 CPU 计算，QPS=4C/100ms=4C/0.1s=40
    • 如果是 IO 密集型应用，请求等待 IO 时可以让出 CPU，因此并发数可以高于 CPU 核数；但不能仅根据“每核可维护 4 个线程”和 10ms CPU 时间直接推出 1600 QPS，实际吞吐量还取决于并发数、响应时间和系统瓶颈
  • 实际压测结果以实测为准，不能据此断定介于 40-1600 之间

3.2. 实践

3.2.1. 创建压测实例

3.2.2. 缓慢增加并发数

  • 200 线程 5s 启动 循环 5 次
  • 400 线程 5s 启动 循环 5 次
  • 600 线程 5s 启动 循环 5 次
  • 800 线程 5s 启动 循环 5 次
  • …

QPS 如果达不到，那么调高并发数

3.2.3. 查看 QPS

1628258497973

  • 查看 90、95、99 线的响应时间是否在预期范围内（比如 50ms 以内），是的话可以看出 QPS 大概 500 左右

4. 如何准确评估实际QPS

使用伪造的数据压测可能并不准确地反映每台机器的QPS，这种方式仅能适用于上线

搞活动的场景需要准确评估QPS，这就需要真实数据。

  1. 容量压测：通过将线上真实的流量引流到需要压测的目标机器上，使用的是真实数据。 设置好需要压测的服务实例、服务路由的权重增长方式、被压测的单机的关键指标（CPU利用率、系统整体负载、QPS、响应时间等）达到的阈值水位后即自动停止压测，以免对生产环境产生大的影响。一旦系统停止压测后，就能在平台上查看到该服务实例在系统资源达到阈值时，单机服务实例所能提供的最大的QPS处理值
  2. 容量规划：能利用服务的单机QPS数据，结合对各种服务器机型处理能力的差异化分析，对到底需要部署多少线上服务器资源才能满足大促活动有更准确的预测

5. 如何优化 QPS

根据 QPS=并发/响应时间，有两条路

  1. 提高并发度。一方面创建更多的线程，当然这里的前提是 CPU 资源是无限的，而现实情况是 CPU 资源是有限的，所以如果创建太多线程必然会让 CPU 忙于线程调度而使得 QPS 下降； 另一方面让火焰图中接口的百分比越多越好，说明 CPU 都用于接口了
  2. 降低响应时间。这就需要分析程序的瓶颈进而优化。运行程序需要 CPU、内存、磁盘、网络，瓶颈必然就是这几个 Linux 性能调优.md

6. 例子

6.1. 频控系统压测

如何设计频控系统

7. 参考

讨论

使用 GitHub 账号参与讨论，评论会保存在 GitHub Issues 中。在 GitHub 查看