简介
- 发压场景设计执行(压测建模-单系统-类-方法-数据存储/多系统-业务场景保真)，-> 压测平台的实现 -> 容量评估，流量预估
- 系统指标以及监控观测(全链路、发压系统)->观测指标->确定系统瓶颈以及高并发下的场景可能的问题：
OOM(内存溢出)
JVM GC情况(YGC、FGC)
CPU 内存 负载
线程池
IO
tcp连接数 /tcp重传、丢包、队列情况、超时延迟、带宽
可用率(业务配置) 分片情况 命中率
TP99/TP999...
各相关中间件、存储域的相应指标 - 系统架构环节，策略执行情况 -> 了解系统的架构 网络拓扑架构+ cdn +集群+分布式+mq(堆积)+缓存(redis，es，hbase....) +db(慢查询...)+链路之间影响 链路有多长辐射范围有多广，链路调用策略，整体链路(下水管道)对多个个机房的蓄水能力考验
- 问题定位，性能优化，流量大_数据大
- 流程规范的制定
Saas化能力分布
- 发压框架(loadrunner，jmeter，ab，nGrinder，locust，各公司自研平台)
- 指标收集：系统指标 网络指标 全链路指标 聚合展示
- 压测流程化 标准化(不影响 不污染)
- 压测常态化 自动化 自助化
- 性能定位 非功能性
- 故障演练 应急方案
- 压测报告自动化，数字化分析
- 流量收集，场景手机
平台化对质量赋能
1. 压测-质量保障-MSA-定量的检验(效率性、可靠性)
思考：
质量控制的标准行业标准自定义标准，质量提升的依据?
Ⅰ 压测前
why 目标 盘点
- 为什么要压测，压测的话要做什么，压测场景的设计，数据建模，链路的深度，链路的辐射， 关键链路梳理 -> 单系统内部、多系统交互、全链路
- 了解目前的压测流程以及使用技术，服务瓶颈发现，是否准备可靠，是否有可改进的地方
- 架构优化的思路，依据结果倒推
。。。。
常规步骤：
1、了解压测背景，制定整体压测计划，自上而下参与 准备：
流量预估、容量评估
1.1. 确定压测目标: 整体系统qps/tps 细分[单系统(读-写) 类、接口、方法] 业务分布 性能需求确定
1.2. 沟通协调：与开发沟通，指定压测指标（压测结果验收指标）---指标来源：容量预估/以往数据值，流量比例，或者之前宕机时的峰值，看是否能承载-> 监控平台，数据看板..
1.3. 脚本准备(成本，是否能达到边际成本最大化)，数据建模-- 依据目标设计压测场景，读写组合，接口组合，业务组合(部署机的业务部署架构)
测试数据整理，当然要考虑如何处理脏数据，数据脱敏，落入影子库
1.4. 预计压测中可能出现的问题，避免到时措手不及，有排查思路，比如从之前压测结果分析，可能出现的问题（比如说上下游哪个系统之前出现过问题），定位，及应急处理措施:
1.4.1 上下游依赖，强弱依赖，弱依赖可以使用开关
1.4.2 服务间通信问题，链路上rpc + mq，超时-重传
1.4.3 负载均衡问题
1.4.4 容灾问题
1.4.5 异常
1.4.6 业务识别
1.4.7. 压测机器准备
1.4.8. 接口压测标记
1.5 结束标准
2. 压测中
单机压测
链路压测
A. 发压开始，从哪个接口开始，还是所有接口一起，还是某几个方法组合，还是对某一个业务进行链路压，依据事先定义好的模型以及压测计划进行......
B. 监控: cpu、 内存、 IO、 带宽、 TP99、 TP999 、tcp连接数、 tcp重传、 qps、 tps、 可用率、 负载、 分片情况、 缓存命中率 gc...=>系统指标
C. 具体的指标值
D. 应急处理，熔断、限流、降级、隔离
E. 碰到的具体问题，根据运维监控数据采集进行分析或者dump分析
链路指标 + 系统指标 + 网络指标 + 故障注入 + 故障演练 +容量预估
限流降级熔断
应用启动顺序
故障根源定位
容量评估
常见故障画像：
1. Application/data：
1. 依赖超时，依赖异常
2. 进程被杀
3. 配置错误，误删，获取超时
4. 心跳异常，比如过zk环境出现问题
5. 流控不合理，下游调用策略问题(比如重复调用高)
6. 业务进程池满，中间件线程池满
2. Virtualization/Storage/Networking
2.1 服务器宕机假死
2.2 磁盘满，慢，坏
2.3 网络抖动，超时，DNS故障
3. Runtime | Middleware | O/S
3.1 负载均衡失效
3.2 CPU抢占
3.2 内存抢占
3.3 数据库宕机
3.4 数据同步延迟
3.5 上下文切换
3.6 数据库连接满
3.7 缓存热点
3.8 缓存切流
F. 故障演练，故障注入，链路上成员的职责和定位，系统外沟通处理，系统内的处理应急
G. 常见系统内部问题：
- 单台tps700多，应用cpu负载高
减少bean -map -json之间的数据转换- 数据库资源利用率高
数据库cpu跑满，但是qps不高，可能是sql执行耗费了时间，没有按索引查找或者索引失效- nginx转发配置问题
- 数据库无压力，应用增加多台后tps不变
nginx转发问题，导致time-wait- 增加服务器数量， tps增长不明显
服务器本身可能不是瓶颈，考虑是不是网络问题，监控网卡流量包，redis是否有报错- 促销
通过redis取数据，tps不高，但cpu占80%，说明程序内部有大量序列化反序列化操作，可能是json序列化的问题- 应用及联效应，造成的雪崩
https://www.cnblogs.com/panchanggui/p/10330924.html
3. 压测结束
数据收集，脏数据处理，整理问题，分析问题，复盘，改善方案为下一次压测准备，输出性能压测报告以及分析建议
依据流程规范，验收所有压测是否停止，环境恢复正常
压测性能分析思路
了解服务的整体架构与设计(系统设计，网络拓扑图)，熟悉各部分组成(包括硬件以及软件层面)、以及部署架构
常见的几个组成:
应用程序: 应用程序之间的通信行为、磁盘或网络上的数据访问模式
操作系统
系统资源: cpu 内存 磁盘IO利用率和延迟
服务器设备
网络环节：网络利用率
是否为混合部署
几个指标：
-
RT(Response time): 用户响应时间 = 服务器响应时间 + 网络时间(网络损耗，不同地域的网络供应商，带宽等)
传输数据量大，带宽上行，下载 -
CPU分析：
检查相关系统日志(自动化运维聚合分析)，web服务器日志，DB日志，分布式中间件，了解cpu状态，是否被占用，被什么服务占用
阀值: 期望系统的平均可用CPU不少于20%
步骤: 查出被什么服务占用
java程序可通过自带的JVM命令工具:jstat、jmap、JConsole
Mysql监控工具:Spotlight、 Monyog、命令行工具
a 计算任务重
b GC频繁
c 上下文切换过多
d 大量异常填充栈信息
- 内存分析
当可用的内存太小，系统进程会被阻塞中，变得缓慢，失去响应，最后导致OOM从而引起应用程序被系统杀死，更严重导致系统重启
虚拟内存也是重要的指标，物理内存不够时，才进行内存交换，把长时间不用的释放掉，但是暂时放在虚拟内存中
创建对象过多
- 网络分析
网络带宽 响应时间 网络延迟 阻塞 网络抖动，机房情况
- I/O
访问应用离不开系统的磁盘数据读写，磁盘的I/O系统是系统中最慢的部分
日志记录可能影响
- 可用率、负载、TP99、TP999
常用性能测试分析调优
1 性能分析调优
2 基于单机的性能分析与调优
3 基于业务流程优化的性能调优
4 基于结构(分布式，业务拆分)的性能分析与调优
性能分析调优:
自底向上：通过监控硬件及操作系统性能指标(CPU、内存、磁盘、网络等硬件资源的性能指标) 链路拓扑结构(SGM系统监控)
自顶向下：通过生成负载来观察被测试等系统性能，比如响应时间、吞吐量
单机的性能分析与调优
常见的系统架构: 用户=>web=>application=>DB 以及中间件
性能分析流程:
Client(压测机) ==> Web Server (Nginx、Tomcat、WebLogic) ==> OS( Linux、Windows) ==> 系统资源(CPU、内存、磁盘、网络) ==> AppServer(应用服务) ==> DB(数据库服务器) 其它相关中间件
- 压测机:
RT(响应时间)
TPS
CPU(cpu利用率、cpu负载)
Mem(物理内存、虚拟内存)
Disks Network(带宽使用率，任务队列长度)
- WebServer:
可用率、负载、TP99、TP999
TCP连接数 可用netstat命令得到
Thread Pool，中间件建立的线程池、监控线程状态
JVM， JVM性能指标，比如GC情况，HEAP使用情况- DB:
中间件与数据库之间的建立的连接数及连接状态
DB Time
一般硬件评价表现
- CPU利用率过高，常见原因：
计算量大，比如远算、连接查询、数据统计
非等闲等待，比如IO等待、资源利用
过多的系统调用，比如Java项目中写日志- 内存吃紧:
过多的页交换与内存泄漏
操作系统会把原内存中的部分内容释放掉(移除或者写入磁盘)，然后把需要的内容载入，这个过程就是页交换- 磁盘繁忙，数据读写频繁
- 网络流量过大
常见压测时的问题，以及定位，应急处理
DB(数据库)
系统的性能好坏很大一部分是由数据库系统、应用程序数据库设计及如何使用数据库来决定的
表设计优化：避免null值，使用INT而非BIGINT
梳理索引 ，explain，选择合适的索引
1 读写分离
2 关键业务进行分区
3 常用查询数据放入es、hbase、redis
4 分库分表
。。。。
如何选择合适的索引
- 选择合适的数据类型
使用可存下数据的最小数据类型，整型<date,time<char,varchar<blob
使用简单的数据类型，整型比字符处理开销更小
使用合理的字段属性长度，固定长度表更快。使用enum，char而不是varchar
尽可能使用not null字段
- 选择合适的索引列
查询频繁的列，where，group by，order by，on...
where条件中出现的列
长度小的列，索引字段越小越好，数据库的存储单位是页，一页中能存下的数据越多越好，避免多次IO
- SQL语句优化
Middleware(中间件)
JVM：监控JVM堆内存使用情况，包括GC屏率，线程状态;
FULL GC 操作是对堆空间进行全面回收，此时是停止响应用户请求的，所以频繁的FULL GC会影响响应时间
Thread pool: 通过netstat统计
DB connections pool : 通过netstat统计
Web Server
页面控制与结果的渲染
关注问题:
a 页面Size ：动态数据、CSS、JS、图片等小小
b 不必要的数据传输
web服务性能优化：
a 页面静态化，减少DB负担
b 减少页面SIze
c 砍掉无用请求，无用数据传输
d 异步动态加载，后台json传输
e 只能DNS以及CDN加速，让响应数据离用户更近，回避缓解网络瓶颈
常见的优化手段
Java代码程序优化（使用池子，减少重复的初始化操作，连接初始化操作，日志落库），串行-> 并行。事件编排，深拷贝优化，去掉不必要的对象构造或调用
配置优化(最佳配置比，如对应线程数)
数据库连接池优化
线程优化
业务流程优化(增加用户操作，button可点击，答题页面，限制请求次数，合并请求次数..路径变短，减少各种IO次数)
集群结构(CDN优化)、部署架构抽取优化
消息体(数据压缩，减少序列化/反序列化，rpc，全量/增量)
中间件(kafka redis..，业务场景，读写)
网络传输(网络 带宽 拓扑结构 延时 报文大小 减少交互次数-如原来需要4次rpc交互确认，是否可以批处理减少到2次，重传设定)
减少不必要的监控节点，减少不必要数据内容
物理机器(带宽 拓扑结构 路径)
不阻塞，均衡的分配
直播优化
直播首开主要耗时： 获取url、dns解析、连接服务器、分析流信息
缓存dns解析，在之前提前解析ip
压测的专有名词
参考地址：
https://blog.csdn.net/zuozewei/article/details/84983834
《。。。》
网友评论