压测流程
一、性能场景分析与创建
-
压测场景
- 业务峰值稳定性:大促业务等峰值业务稳定性考验
- 新系统上线:准确探知站点能力,防止系统一上线即被用户流量打垮
- 技术升级验证:大的技术架构升级后进行性能评估,验证新技术场景的站点性能状态
- 容量规划:对站点进行精细化的熔炼规划,为系统扩容,性能优化提供数据参考,节省成本投入,提高资源利用率
- 性能探测:探测系统中的性能瓶颈点,进行针对性优化
-
压测策略(方法)
- 负载测试:系统在不同负载下的性能表现,发现系统性能的拐点,从而找出系统最佳性能
- 压力测试:评估系统处于或超过瓶颈时,系统的运行状况,关注点在于系统峰值负载或超出最大载荷情况下的处理能力,同时需要关注负载减小后,系统的恢复能力
- 基准测试:通过基准测试建立一个已知的性能水平(称为基准线),当系统的软硬件发生变化后再进行一次基准测试,确定变化对性能的影响
- 配置测试:不断调整系统软硬件各种配置,使得系统性能达到最优
- 稳定性测试:在特定的负载(略高于正常负载)下,持续施压,验证系统能否长期稳定运行
- 负载测试:系统在不同负载下的性能表现,发现系统性能的拐点,从而找出系统最佳性能
-
系统架构梳理(分析潜在风险点)
技术架构,分层机构,模块划分,数据库、缓存、消息队列等中间件的使用
-
压什么?
- 关键业务的接口:根据业务确定
- 访问量的的接口:可以找开发提供接口访问排行榜,前20-30个
-
压测方案编写
- 背景和目的
- 业务和技术指标
- 涉及范围和链路:需要和相关的团队一一对其
- 压测实施里程碑:每轮压测的目标和要做的事情
- 压测任务及进度:整体的压测任务拆分以及当前进度,提前评估风险
- 压测模型和策略:类似于功能测试过程中的用例评审,查漏补缺的过程
二、压测脚本编写及调试
-
编写
一定要写响应断言 -
调试
- 查看结果树
- 调试取样器
- JMeter日志
- 用表格查看结果
- charles或fiddler
三、脚本执行
- JMeter单机压测
Jmeter是纯Java应用,对CPU和内存的消耗较大。在大量并发情况下,容易发生CPU和内存溢出的问题。因此,建议单台机器的线程数不要超过500个,以保持较好的性能和稳定性。 - JMeter分布式压测
- 空接口压测
四、指标监控
- 业务指标:如并发用户数、TPS(系统每秒处理事务数)、成功率、响应时间
- 硬件指标:如CPU、内存、磁盘、网络I/O的使用率
- 软件指标:线程池、JDBC连接池、JVM(GC/FULL GC/堆大小)、慢SQL、等待/死锁、缓存命中
五、定位瓶颈
-
确保压测流量完全打到服务
- 网络层带宽
- ip地址限流
- slb自动伸缩失败
- Nginx负载均衡失败/Nginx机器性能受限
- 限流熔断降级
- 施压机器性能瓶颈
-
如果是某个硬件指标的问题,需要深入分析
- CPU高: 使用top查看占用资源最高的进程、根具PID查询占用最高的线程,如果是java可以用jstack查看线程正在执行的堆栈
- 内存高:查看哪个进程占用内存多,以及是否有大量的虚拟内存交换(swap)
- 磁盘I/O高:通过减少日志输出、异步
- 网络I/O:查看传输内容大小,可以通过压缩传输内容、在本地设置缓存、分多次传输等降低网络的压力
-
如果是中间件的问题,需要深入分析
- 线程池不够:增加线程,并弄清楚为什么线程阻塞
- JDBC连接池:增加连接数,并弄清楚连接未释放的原因
-
如果是数据库的问题----80%
查看慢sql,所引命中率,锁等 -
如果上述指标正常可以考虑缓存、逻辑、算法等的问题
六、性能调优
- 性能调优后必须进行功能回归测试
- 缓存
- 异步
- 预先处理
- web标准提供了至少两种提前加载方式:preload、prefetch
- 预加载
- 时空转换
- 时间换空间:数据放到磁盘、需要时再读取
- 空间换时间:数据放到内存、cdn