对性能优化的理解总结
索引
什么是性能优化
性能优化和故障解决的区别:
- 性能优化关于全局和流程，关注流程之间的协调性
- 而故障解决关注局部，关注局部有效性
目标的确定和衡量
确定目标
-
慢的范畴
- 业务范围层
- 影响区域范围层
-
慢的定性或者定量描述
不同人员的操作频率也会对于快慢的期望产生重大的影响，必须懂得管理操作者的期望值
对于操作的业务往往可以忍受比较慢的速度，而对于频繁操作的业务则很难忍受
衡量标准
对于非交互式的批处理应用，优化目标相对容易确定，一般可以用每分钟处理业务量或者每个业务单元多长时间来进行衡量
对于局部终端的交互式应用，直接的定性描述或者实际衡量的响应是一种可以接受的简单优化目标衡量方式
采用定性和定量结合的方式来完成优化目标衡量：
-
性能指标-
吞吐量
采用事务数量或者特征语句的执行次数来确定吞吐量- QPS代表的是每秒的查询数量
- TPS代表的是每秒事务的数量
- HPS代表的是每秒的HTTP请求数量
-
响应速度
访问局部终端使用人员的感知并且进行定量的时间记录
特征语句的每次执行时间
-
-
响应时间-
平均响应时间
服务接口的平均处理能力
计算方式就是把所有的请求所耗费的时间加起来，然后除以请求的次数 -
百分位数
圈定一个时间范围，把每次请求的耗时加入一个列表中，然后按照从小到大的顺序将这些时间进行排序
-
-
并发量
系统能够同时处理的请求数量，反映的是系统的负载能力 -
秒开率
主要针对的是前端网页或者移动端APP来说的 -
正确性
无论我们以何种方式，何种手段对应用进行优化，优化后的交互数据结果必须是正确的
一般来说，响应时间越快，吞吐量越高，但是随着吞吐量逐渐达到一个限制值之后，响应时间将迅速下降
也就是说，任何资源、设备或者服务其服务能力是有限制的，当达到限制的时候其服务能力将迅速下降。
工作分类
-
上线优化或者从未达到过性能期望的系统优化工作
这类缺乏性能设计考虑的业务系统基本是由于开发人员考虑不周导致的 -
具有相对明显或者不明显感觉的响应速度逐步变慢的系统优化
随着时间的推移，数据量变大、业务发展、访问量变多、数据不断被分享使用等变化度量逐渐变化，导致业务系统在渐渐的变慢，直到性能表现不可忍受 -
运行过程中突然变慢的系统优化
业务系统故障bug导致 -
基于降低资源消耗的系统优化
明显的吞吐量或者响应时间异常 -
预防性的日常性能优化
当日常监测性能因子达到预先设定的警戒值之后就进行优化，使其回到正常范围或者减缓其增加速度。主要在于延缓业务系统的硬件扩容，延迟资金投入，合理安排扩容采购窗口，避免业务系统出现性能问题，提高服务质量
没有无缘无故的性能问题，
任何性能问题都是由于某种或者多种变化引起的
- 业务量的变化
- 访问量的变化
- 并发量的变化
- 数据量的变化
- 数据结构的变化
- 代码的变化
性能优化的任务就是确定性能影响因子 => 检测它们 => 记录它们 => 检查它们变化
⚠️注意⚠️：必须认识到并不是任何变化都会引起性能异常
误区
-
性能优化是一门艺术
性能优化目标的完全可量化确定决定了其是一门科学，- 性能优化的结果可测量，可量化。
- 性能优化的大量相关性可以被量化，具有相对客观的标准。
- 性能优化的改善必须可测量，可量化，具有高度的严谨性
-
性能优化工作需要是全面的高手才能做
性能优化工作者真正需要的是具有广泛的知识和视野，具有全局性观点和流程观点，具有较好的客户沟通能力等等 -
测试系统性能很好，生产系统为什么不行？
任何业务系统都在一个独特的上下文中运行，业务系统运行的好坏很大程度不依赖于业务系统本身，而是依赖于业务系统运行上下文环境。 -
针对特定表现的性能问题，有一套标准的解决方案
性能问题总是和上下文环境相关，其解决方案自然也和上下文相关 -
只要资源充足，数据库性能就不会差
资源只是数据库性能表现的一个方面，比较资源而言，并发性或者吞吐量是数据库性能更加重要的一个影响因素。另外还存在着资源没有被充分利用的问题 -
主要数据库性能好，业务系统性能必然好
随着业务系统复杂化，数据库在业务系统影响链条中的地位越来越低，数据库的性能只是业务系统性能的一个环节
测量、基线和性能优化
查找导致性能变差的原因：只要把每个可测量的指标值和该指标的基线值进行比较，出现大规模偏差一般情况下就是性能问题的根源所在
为此必须进行一下三个步骤：
-
建立业务系统可测量的性能指标
吞吐量和响应时间的因果分析测量体系和相关性分析测量体系。
基于因果关系确认的艰难性，我们更多的基于相关性进行分析测量 -
建立性能基线
一般来说，对于每个不同的业务，至少需要建立两根基线：峰值业务基线和正常业务基线 -
建立基于沟通的基线：感性基线
基线以吞吐量和响应时间为基础，从三个方面进行描述：性能感受、运行用户、运行业务
优化需要注意的问题
-
不要过早优化
除非必要,一开始不要优化(尤其是开发阶段) -
不要墨守成规
有些优化准则已经过时,需要考虑当下的软硬件环境 -
聚焦性能瓶颈
不要过分强调某些系统级指标,如cache 命中率,而应该聚焦性能瓶颈点 -
不盲从、先定位瓶颈点
不盲从，测试、找到系统的性能瓶颈，再确定优化手段 -
权衡成本和利益
注意权衡优化的成本和收益（有些优化可能需要现有架构做出调整、增加开发/运维成本） -
明确优化的目标
优化的目标是用户体验、降低硬件成本（降低集群规模、不依赖单机高性能） -
针对真实情况优化
测试环境的优化手段未必对生产环境有效（优化需要针对真实情况）
