【性能测试】性能测试学习笔记(1)

时间:2023-01-31 19:37:00

性能测试学习笔记(1)

确认性能需求

  • 估算吞吐量/响应时间
  1. 有监控就check监控中接口的吞吐峰值(TPS/QPS)和响应时间峰值
  2. 没有监控,线上没有流量

    a. 可以先预定一个响应时间(可接受的底线值),然后开始做压测,观察在这个响应时间之内的最大吞吐量。

    举个栗子:

    服务:
    获取配送人员的当前地理位置

    线上场景:
    X包配送人员1W
    Y队配送人员2W
    同时在线最多人数 8k

    响应时间(要求):
    10ms

    推算吞吐(通过压测):
    线性增加压力,观察响应时间,当加到一定压力时,响应时间达到要求,记录压力值

    b. 根据线上的业务需求来推算性能指标

    举个栗子:

    服务:
    配送人员地理位置上传服务

    线上场景:
    X包配送人员1W
    Y队配送人员2W
    同时在线最多人数 8k

    推算吞吐:
    8k/s

    响应时间:
    根据推算吞吐去做压测(主要观察90线和95线,平均值和中位数做参考),获取响应时间

压测过程中的关注点

测试前的关注点:

  1. 确定好性能需求
  2. 确定好压测时间(县上压测,为了降低影响,就选流量最小的时间点)
  3. 确定好压测工具,压测脚本(输入尽可能与线上一致)
  4. 确定是否要压到拐点?

测试过程中关注点:

  1. 吞吐是否压得上去?
  2. 是否有业务错误?(超时,上传位置太快等业务错误)
  3. 响应时间是否满足要求?
  4. 服务器性能指标是否正常?(htop命令监控)
  5. DB,Readis的运行状况是否良好?
  6. 是否有必要压到拐点

测试结束后关注点:

  1. 压测的输入输出是否无误差,无缓存等其他因素影响(输入数据尽可能的与线上情况一样!一样!一样!)
  2. 压测结果是否满足性能需求?
  3. 压测产生的垃圾数据记得清理

性能测试,做不难,难在分析!难在分析!难在分析!

  1. 为什么加了压力,系统吞吐上不去?
  2. 为什么加到一定压力,DB或者redis发生抖动?
  3. 为什么加到一定压力,系统吞吐变慢?响应时间变大?是因为已经超负荷还是系统性能太差?
    ... ...