吐血整理，性能测试-性能常遇问题分析原因+解决（超细）

前言

1、常见的性能问题与原因

1）网络带宽

网络对性能的影响不言而喻。
如果带宽不足，单位时间内的请求过多，就会导致数据包的传输延迟较大。

如果网络不稳定，也会导致RT的曲线抖动较为剧烈，产生毛刺甚至丢包，这个时候P90/P99的数值也可能变大。
因此稳定和足够的网络带宽，对系统的性能来说是很重要的。

2）负载均衡

现在的SLB层已经优化的足够好，但如果负载均衡出现问题，可能会导致流量分发不均匀，导致部分应用节点流量异常，健康检查不通过从而被踢下线。

甚至服务注册重试失败或者弹性扩容不够及时，还会导致可用的节点承受了较多的请求最终导致雪崩效应。

3）安全策略

现在的软件系统，常见的安全防护策略有ddos高防以及WAF，一般都是部署在SLB和流量网关之间或者更上层。

安全防护策略常见的场景有异常检测、输入验证、安全补丁、状态管理以及基于规则和异常的保护功能。

这些安全策略能够有效的保护系统不受到一些恶意的攻击和侵入，但这些策略生效也是需要耗费时间的。

4）流量网关

上面提到的几个部分都可以看做是互联网时代的基础通用层，而网关是伴随着微服务和容器化出现的，作为用户流量的系统入口，网关也承担了较多的功能，比如：
日志
身份鉴权
灰度发布
限流熔断
可观测性metrics
应用限流apm tracing

上述的功能，无论是身份鉴权还是可观测性的metrics的实现，都需要耗费一定时间。
特别是对于请求的RT比较敏感的业务，对流量网关功能的耗时要求更为严格。

5）Web应用层

近几年前后端分离的系统设计越来越多，web层更多的负责页面的渲染展示和部分讨好用户的交互设计。
如何让用户更快的感知到他所感兴趣的东西，这个时候CDN和缓存就派上用场了。

利用CDN和缓存的特性“就近加载”，让用户感知到的性能更快，也是性能优化领域很重要的一点。

6）APP应用层

前面讲了web层负责页面渲染展示和友好的交互，那App应用层（即我们常说的后端服务）则更多的负责逻辑计算。
逻辑计算是很吃资源的，当然和它的一些参数配置以及技术架构也有较大关联。

常见的影响后端服务性能的因素如下：

硬件资源：如CPU/Memory；
参数配置：如Activethreads/TimeOut；
缓存配置：缓存中的大Key及缓存命中率；
并行计算：请求下游依赖是串行还是并行？
代码逻辑：最经典的例子——for循环无线套娃；
日志处理：特别是异常日志的处理以及生产日志级别；
处理机制：同步还是异步？如果是异步，MQ容量及消费能力如何？
推荐阅读：认清性能问题

7）数据存储层

数据存储层我们通常理解为数据库。数据库层面影响性能的因素应该是最常见也是最多的。

比如：
锁：不合理的锁使用导致的请求等待；
索引：未加索引或索引未生效导致慢SQL；
数据量：表数据量过大导致的读写变慢等问题；
针对业务扩张以及数据量变大的问题，常见的优化策略有分表、数据库垂直拆分、读写分离等；

2、压测不是发现问题的唯一手段

回到性能定位分析和优化的话题上，关于性能优化，如下三点是必须铭记的。

1）性能优化的目标

在保持和降低系统99%RT的前提下，不断提高系统吞吐量，提高流量高峰时期的服务可用性。

2）性能优化的挑战

日益增长的用户量（带来访问量的提升，大数据量的存储和处理）；
越来越多样的业务（业务的不断迭代和发展，会使其复杂性指数提升）；
越来越复杂的系统（为了支撑业务迭代发展，系统架构会变得很复杂）；
性能优化的路径
降低响应时间；
提高系统吞吐量；
提高服务可用性；
PS：三者关系在某些场景下互相矛盾冲突，不可兼得！

3）性能优化的道法术器

基于上述关于性能优化的几点内容，结合我个人的实践经验和看法，性能定位和分析分为下面四个境界。

道：熟悉业务逻辑，了解系统架构；
法：掌握技术原理，熟知问题定位和分析优化的软件工程方法论；
术：不断实践踩坑，总结归纳性能验证、定位分析的方法和经验；
器：熟练使用性能测试、监控追踪、问题分析和优化的各种工具并擅加利用；

3、如何让系统运行的更快更稳定

1）时间空间

软件系统的三高（高性能、高可用、高稳定）要求，归根结底实际上需要在成本、收益、风险之间做取舍，我们很难做到用最低的成本达到最好的效果。

有个很早之前的优化理论，叫做“时间换空间，空间换时间”，讲的就是在响应时间和硬件资源消耗之间做平衡。性能优化的关键在于平衡各部分组件的性能平衡点，

如果CPU资源有空闲，但是内存使用紧张，便可以使用时间换空间的策略，达到整体的性能优化；反之CPU资源紧张，内存资源有空闲，则可以使用空间换时间的策略，提升整体性能。

2）分层优化

请求的处理过程要经过多个链路环节，除了优化耗时最长难度和成本较低的环节之外，在每个环节都进行一定优化，则对整体性能的提升有很大帮助。下面是流量高峰时的一些优化或者说应对案例：

3）数据库

扩容：DB是有状态服务，计算层便于扩容，将DB节点放到容器中，有需要扩容；
灾备：对于大流量读场景可通过流量切换方式，将部分流量迁移到备份集群分流；
巡检：慢SQL是常见的问题，可通过自动监控和历史数据分析，提供辅助式决策；

4）应用层(计算层)

限流：控制访问应用的流量在系统承载范围内
在业务请求入口（网关）限流，避免内部互相调用放大流量；
限流是个演进状态，从连接池、IP、指定SQL到更细的层级粒度做限流；
每个调用层都做限流，每个应用先保证自己可用，对其他依赖调用要做到“零信任”；

降级：强依赖通过熔断做紧急处理，弱依赖提前主动降级
主动降级：提前进行风险识别，然后针对性的降级，可降低已知的风险；
紧急降级：假设出现重大的问题，才需要决策是否启用的方案（风险较大）；
预案平台：预案平台的目的是留痕，方便后续把限流降级等配置恢复回来；
熔断：熔断下游强依赖的服务

双十一零点的前半小时， 做一个动态推送，把日志关掉；
真正流量来的时候，留一台机器来观察错误和异常的日志；
隔离：核心和非核心业务做隔离

身份识别和业务隔离案例如下：
RPC group分组：假设有100个节点，40个给核心业务(交易)，60个给其他业务；
业务身份：中台架构可通过业务身份把订单秒杀等应用打上标记，便于隔离区分；

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最精彩的不是实现梦想的瞬间，而是追梦路上那个永不言弃的自己。那些看似遥不可及的目标，终会在你日复一日的坚持中触手可及。别怕慢，怕的是停下；别怕难，怕的是放弃！

你比自己想象的更强大！每个挫折都是成长的契机，每次坚持都在改写命运的轨迹。当别人选择放弃时，你的执着就是胜利的开始。向前奔跑吧，整个世界都会为追光者让路！