全链路压测汇总思路

2019-10-27  本文已影响0人  上山走18398
简介
  1. 发压场景设计执行(压测建模-单系统-类-方法-数据存储/多系统-业务场景保真)，-> 压测平台的实现 -> 容量评估，流量预估
  2. 系统指标以及监控观测(全链路、发压系统)->观测指标->确定系统瓶颈以及高并发下的场景可能的问题：
    OOM(内存溢出)
    JVM GC情况(YGC、FGC)
    CPU 内存 负载
    线程池
    IO
    tcp连接数 /tcp重传、丢包、队列情况、超时延迟、带宽
    可用率(业务配置) 分片情况 命中率
    TP99/TP999...
    各相关中间件、存储域的相应指标
  3. 系统架构环节，策略执行情况 -> 了解系统的架构 网络拓扑架构+ cdn +集群+分布式+mq(堆积)+缓存(redis，es，hbase....) +db(慢查询...)+链路之间影响 链路有多长辐射范围有多广，链路调用策略，整体链路(下水管道)对多个个机房的蓄水能力考验
  4. 问题定位，性能优化，流量大_数据大
  5. 流程规范的制定
Saas化能力分布
  1. 发压框架(loadrunner，jmeter，ab，nGrinder，locust，各公司自研平台)
  2. 指标收集：系统指标 网络指标 全链路指标 聚合展示
  3. 压测流程化 标准化(不影响 不污染)
  4. 压测常态化 自动化 自助化
  5. 性能定位 非功能性
  6. 故障演练 应急方案
  7. 压测报告自动化，数字化分析
  8. 流量收集，场景手机
    平台化对质量赋能
1. 压测-质量保障-MSA-定量的检验(效率性、可靠性)

思考：

质量控制的标准行业标准自定义标准，质量提升的依据?

Ⅰ 压测前

why 目标 盘点

  1. 为什么要压测，压测的话要做什么，压测场景的设计，数据建模，链路的深度，链路的辐射， 关键链路梳理 -> 单系统内部、多系统交互、全链路
  2. 了解目前的压测流程以及使用技术，服务瓶颈发现，是否准备可靠，是否有可改进的地方
  3. 架构优化的思路，依据结果倒推
    。。。。

常规步骤：

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. 常见系统内部问题：

  1. 单台tps700多，应用cpu负载高
    减少bean -map -json之间的数据转换
  2. 数据库资源利用率高
    数据库cpu跑满，但是qps不高，可能是sql执行耗费了时间，没有按索引查找或者索引失效
  3. nginx转发配置问题
  4. 数据库无压力，应用增加多台后tps不变
    nginx转发问题，导致time-wait
  5. 增加服务器数量， tps增长不明显
    服务器本身可能不是瓶颈，考虑是不是网络问题，监控网卡流量包，redis是否有报错
  6. 促销
    通过redis取数据，tps不高，但cpu占80%，说明程序内部有大量序列化反序列化操作，可能是json序列化的问题
  7. 应用及联效应，造成的雪崩
    https://www.cnblogs.com/panchanggui/p/10330924.html
3. 压测结束

数据收集，脏数据处理，整理问题，分析问题，复盘，改善方案为下一次压测准备，输出性能压测报告以及分析建议
依据流程规范，验收所有压测是否停止，环境恢复正常

压测性能分析思路

了解服务的整体架构与设计(系统设计，网络拓扑图)，熟悉各部分组成(包括硬件以及软件层面)、以及部署架构
常见的几个组成:
应用程序: 应用程序之间的通信行为、磁盘或网络上的数据访问模式
操作系统
系统资源: cpu 内存 磁盘IO利用率和延迟
服务器设备
网络环节：网络利用率
是否为混合部署

几个指标：

  1. RT(Response time): 用户响应时间 = 服务器响应时间 + 网络时间(网络损耗，不同地域的网络供应商，带宽等)
    传输数据量大，带宽上行，下载

  2. CPU分析：

检查相关系统日志(自动化运维聚合分析)，web服务器日志，DB日志，分布式中间件，了解cpu状态，是否被占用，被什么服务占用
阀值: 期望系统的平均可用CPU不少于20%
步骤: 查出被什么服务占用
java程序可通过自带的JVM命令工具:jstat、jmap、JConsole
Mysql监控工具:Spotlight、 Monyog、命令行工具

a 计算任务重
b GC频繁

c 上下文切换过多
d 大量异常填充栈信息

  1. 内存分析

当可用的内存太小，系统进程会被阻塞中，变得缓慢，失去响应，最后导致OOM从而引起应用程序被系统杀死，更严重导致系统重启
虚拟内存也是重要的指标，物理内存不够时，才进行内存交换，把长时间不用的释放掉，但是暂时放在虚拟内存中
创建对象过多

  1. 网络分析

网络带宽 响应时间 网络延迟 阻塞 网络抖动，机房情况

  1. I/O

访问应用离不开系统的磁盘数据读写，磁盘的I/O系统是系统中最慢的部分
日志记录可能影响

  1. 可用率、负载、TP99、TP999
常用性能测试分析调优

1 性能分析调优
2 基于单机的性能分析与调优
3 基于业务流程优化的性能调优
4 基于结构(分布式，业务拆分)的性能分析与调优

性能分析调优:
自底向上：通过监控硬件及操作系统性能指标(CPU、内存、磁盘、网络等硬件资源的性能指标) 链路拓扑结构(SGM系统监控)
自顶向下：通过生成负载来观察被测试等系统性能，比如响应时间、吞吐量

单机的性能分析与调优
常见的系统架构: 用户=>web=>application=>DB 以及中间件
性能分析流程:

Client(压测机) ==> Web Server (Nginx、Tomcat、WebLogic) ==> OS( Linux、Windows) ==> 系统资源(CPU、内存、磁盘、网络) ==> AppServer(应用服务) ==> DB(数据库服务器) 其它相关中间件

  1. 压测机:
    RT(响应时间)
    TPS
    CPU(cpu利用率、cpu负载)
    Mem(物理内存、虚拟内存)

Disks Network(带宽使用率，任务队列长度)

  1. WebServer:
    可用率、负载、TP99、TP999
    TCP连接数 可用netstat命令得到
    Thread Pool，中间件建立的线程池、监控线程状态
    JVM， JVM性能指标，比如GC情况，HEAP使用情况
  2. DB:
    中间件与数据库之间的建立的连接数及连接状态
    DB Time
一般硬件评价表现
  1. CPU利用率过高，常见原因：
    计算量大，比如远算、连接查询、数据统计
    非等闲等待，比如IO等待、资源利用
    过多的系统调用，比如Java项目中写日志
  2. 内存吃紧:
    过多的页交换与内存泄漏
    操作系统会把原内存中的部分内容释放掉(移除或者写入磁盘)，然后把需要的内容载入，这个过程就是页交换
  3. 磁盘繁忙，数据读写频繁
  4. 网络流量过大

常见压测时的问题，以及定位，应急处理

DB(数据库)
系统的性能好坏很大一部分是由数据库系统、应用程序数据库设计及如何使用数据库来决定的
表设计优化：避免null值，使用INT而非BIGINT
梳理索引 ，explain，选择合适的索引
1 读写分离
2 关键业务进行分区
3 常用查询数据放入es、hbase、redis
4 分库分表
。。。。

如何选择合适的索引

  1. 选择合适的数据类型

使用可存下数据的最小数据类型，整型<date,time<char,varchar<blob
使用简单的数据类型，整型比字符处理开销更小
使用合理的字段属性长度，固定长度表更快。使用enum，char而不是varchar
尽可能使用not null字段

  1. 选择合适的索引列

查询频繁的列，where，group by，order by，on...
where条件中出现的列
长度小的列，索引字段越小越好，数据库的存储单位是页，一页中能存下的数据越多越好，避免多次IO

  1. 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
《。。。》

上一篇下一篇

猜你喜欢

热点阅读