性能测试--总述

性能测试是一个很大的话题；包含客户端、服务端性能、各中间件的性能；一般来说只要有io操作，可能存在压力的场景都可能出现性能瓶颈；同时性能测试是整个质量体系最为重要的几个专项之一，性能会影响用户体验，服务的稳定性，好的性能架构能有效的节省成本（机器）；性能的原理，是通过模拟压力来对业务场景建模，然后监控性能指标，分析数据，得出性能结论，验证问题或结论，并总结成方法论；

性能流程

需求分析
设计方案
准备环境
构造数据
业务建模
执行监控
分析优化
结论并验证
方法论落地

需求分析

分析性能需求；基于需求做后续的性能工作；这里要明白，性能测试是基于目的+架构+风险的专项测试；常见的性能需求场景如下：

线上出现性能问题，需定位解决；
大促活动等端时高性能需求，需评估性能；
容量规划；

设计方案

不同性能需求，出发点不一样，故着重点也不一样；设计方案要解决几个问题：

是什么：测试对象分析（业务/设计/架构）；测试合规指标的制定（预期性能指标（TPS/TIME/性能指标））/性能方案（建模/覆盖/监控/卡点）；人员规划（参与人员/权责/容量成本/时间）；
怎么样：先和业务方（发起方）沟通确定目标、预期这些；同步给相关角色，让他们了解并提前准备；开会同步，确认；

具体实施如下：

性能标准

作用：可以基于单节点的性能数据和线上比对，判断性能环境的仿真度；卡点、性能指标，超出阈值，则触发异常分析流程；确定一个优化目标，决定什么时候结束；
依据：当前压力，增长、预期情况（二八原则）；竞品的性能数据；线上的性能表现（最近一年峰值，最近三月/半年的平均增长率，预估一个1.5年后的压力数据，作为tps预期值）；
具体：QPS达到300/top50响应时间不能超过500ms，最大响应时间不能超过2s,平均响应时间200ms以内；（不基于业务和线上数据设计的这个标准并无意义）

准备环境

环境最重要的一点是有效性，需要兼顾效果和成本；设计原则如下：

能用线上环境最优；能兼顾真实性和成本；但需要做好隔离、监控、卡点、恢复，这需要架构支持这种能力，会增加架构和代码设计成本；
维护一个最小集群的云服务的性能镜像环境；优点是和线上隔离了，缺点需要定时同步服务数据，也需要做好隔离和拦截，需要确定有效性；
测试环境做为性能环境；这种基本没有有效性，而且无法量化，只能单纯用来定位问题，但至少也要做到路由控制，持续集成和微服务；

构造数据

造数，需要根据业务特征、设计、数据特点来，常见的造数的方式：

线上快照
代码批量生成
随机数据

业务建模

有两块需要考虑；分析需要覆盖的施压对象，然后仿真施压，具体如下：

用户仿真：通过jmeter来仿真施压；施压策略需要考虑（预热、思考时间、分布式施压、依赖数据io对性能影响）；施压方式有两种按固定压力（并发）；按定量的处理能力（TPS）

IO施压：
MYSQL施压：sysbench(覆盖只读模式/读写混合模式/走或不走索引的模式)
监控：
Redis施压：工具redis-benchmark

监控

• MySQL监控
  • 命令
• [redis监控]（监控平台）
  • [监控命令]（哨兵模式/命令）
• pprof可视化工具+热力图

分析优化

分压，动态均衡分配机制，时间换空间，常见的分析优化策略如下：

方向：架构、设计、容灾、代码、网络、存储、安全
缓存策略

常见问题：

1、广告请求接口耗时过长问题（原因。服务端和大数据过滤策略重叠,redis查询耗时问题）
2、网关接口压力太大太重，拆分
3、
性能优化大纲