ThinkerQAQ

NOTE

2.2 压力测试

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

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

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

1. 什么是压力测试

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

2. 为什么需要压力测试

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

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

3.1. 估算

  • 可以用并发、响应时间和吞吐量之间的关系做粗略估算，但 CPU 核数、线程数并不能直接推出系统 QPS。
    • 计算密集型应用通常更容易受 CPU 饱和限制。
    • IO 密集型应用还会受到连接池、线程/协程模型、网络、存储和依赖服务等因素影响。
  • 最终容量仍应通过逐步升压的实际压测确认，并同时观察延迟、错误率和资源饱和度。

3.2. 实践

3.2.1. 创建压测实例

3.2.2. 缓慢增加并发数

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

如果负载生成端仍有余量，可以逐步提高并发或到达率，同时观察系统是否进入饱和。

3.2.3. 查看 QPS

1628258497973

  • 查看 p90、p95、p99 响应时间是否在业务目标范围内，并结合错误率和资源利用率判断当前 QPS 是否可持续。

4. 如何准确评估实际QPS

使用伪造数据的压测可能不能准确反映真实业务下的单机 QPS，测试数据和访问分布越接近真实场景，容量结论越可信。

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

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

5. 如何优化 QPS

从系统能力上看，优化通常围绕提高可持续并发处理能力、降低服务时间和消除资源瓶颈展开

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

6. 例子

6.1. 频控系统压测

如何设计频控系统.md

7. 参考