压测场景
- 业务峰值稳定性 ,比如促销活动
- 新系统上线,新的系统上线钱验证
- 技术升级验证,系统架构改造升级后性能评估
- 容量规划,就系统进行精细化的容量规划,为系统扩容,性能优化提供数据参考,节省成本,提交资源利用率
- 性能探测,探测系统中的性能瓶颈点,进行针对优化
压测策略
- 负载测试,系统在不同负载下的性能表现,发现系统性能拐点,用户并发逐级阶梯式增加并发数查看系统性能指标变化
- 压力测试,评估超过预期负载时系统的运行状态,关注系统峰值字符或超出最大负载情况的处理能力,同时也要关注负载减小后系统恢复能力
- 基准测试,通过基准建立一个已知的性能水平,当系统软硬件环境变化之后进行一次,确定那些变化对性能影响
- 配置测试,不断调整不同软硬件配置,系统性能达到最优的配置(JVM、线程池、连接数、硬件带宽cpu内存)
- 稳定性测试,在特定负载(略高正常负载下),持续试压,验证系统长期下稳定性
性能测试调研 端到端请求架构流程
理清楚后端系统架构 ,分析潜在风险点
nginx负载均衡配置错误,导致分发到网关机器不均
mysql,慢sql 慢查询,jdbc池不够
redis ,容灾,降流
性能场景设计
业务范围
筛选主要接口进行性能测试
- 关键业务 (主流程接口,如下单支付)
- 访问量大 (不是关键业务,如进入京东首页在一些加载访问量大,但没啥用)
- 逻辑复杂 (平时调用量不大,但同时操控多张表,调用多个接口等)
- 运营推广活动
业务操作流程
如,通过抓包来分析整体流程,参数如果进行传递的
业务跑配比
如一共1万人,2千人下单,8千人在浏览商品
准备工作
- 数据准备
压测一万人,一万的账号和密码csv文件,商品库存等 - 机器准备
linux机器 - 人员准备
运维开发人员 - 全链路压测
传统单接口
涉及全业务流程,在生产环境
脚本执行
执行时用 命令行方式启动
单机性能限制,cpu内存,修改jemter默认内存值 (通常单机限制2000线程数)
单机带宽不够 ,执行机器返回性能垃圾,吞吐量响应时间等,另一个机器去访问被测网站 正常,带宽限制了
负载高性能损耗大,延时高,数据不准
Liunx分布式 vs k8s集群
解决需要用到linux分布式压测
调度机 分发脚本汇总结果-> 调用jemter执行机 -> 被测系统
监控指标
-
业务指标
并发数,tps(系统每秒处理事务数)、成功率、响应时间 -
硬件指标
cpu利用率、内存利用率、磁盘i/o、网络i/o -
软件指标
线程池、jdbc连接池、jvm(gc/full、gc/堆大小)、效率低下sql、锁等待/死锁、缓存命中率、会话、进程
docker containers(容器)
prometheus(普罗米修斯,会监控收集系统数据)
grafana(可视化数据监控平台,展示收集数据)