当我们的系统达到了一定的量级/用户之后,或多或少都会接触到性能优化相关的内容,大家可能根据自己的经验,都有自己的一套优化手法。但是可能还有很多人面对性能问题时,可能无从下手。或者在性能优化的过程中,会踩不少坑。
关注公-众-号:IT老哥,领取300G学习资料
所以这个性能优化系列主要会通过几个方面的内容,让大家对于整个性能优化的过程有一个整体的了解,并且通过一些常见的优化手段和案例,让大家少走一点弯路。
大家都没有过这样的时候:
我觉得、我感觉、不管有没有用,做了再说。但是我们在发布了一个优化版本之后,要通过什么方式去验证它的效果呢?
优化不是凭感觉,需要有实际的数据作为支撑
我们每次优化,都需要有实际的数据来做验证,根据数据来调整我们的优化方向和内容。那哪些数据可以做为性能指标呢?
系统性能指标主要是针对我们的应用的整体情况,主要包括:RT(请求响应时间)、QPS、TPS、吞吐量等
中间件主要包括我们的依赖的虚拟机、外部系统或框架,可能包括:JVM、DB、Redis等
资源就是我们系统依赖的容器、虚拟机或物理机上的三大马车:CPU、IO、MEMORY
稳定性主要包括我们系统的SLA、宕机恢复时间等
可扩展性主要关注系统是否是可以线性扩展的
知道了上面这些指标后,我们可以想一下,我们对自己的系统是否真的了解呢?下面两个问题大家可以尝试回答一下:
如果你无法回答这两个问题,那可能下面的内容会对你有一点帮助。
定义自己系统的可用指标
在什么指标下,我的系统是可用的
最基础的一点是,我们最少需要知道在什么样的指标下,我的系统是可用的(可正常对外提供服务)
举个栗子
,当我的系统满足以下指标时,它才是可用的:
CPU | 使用率 < 70% |
RT | 99线 < 40ms,95线 < 20ms,90线 < 5ms |
内存 | 使用率 < 70% |
GC | FullGC < 1次/天 MiniorGC < 5次/分钟 |
上面举例不代表实际情况
,大家需要根据自己系统的实际情况
来制定对应的指标
在可用性指标下,我的系统承载能力是多少
只要在这个量级以下,来多少都不怕
在满足了上面的可用性指标的情况下,我们还需要确定在常规的流量比例下,我们系统的极限
在哪里(QPS、TPS、吞吐量的值)。
比如某个系统的可用性指标:
我们只有知道了系统的可用极限
,才能够在需要扩容的时候做到心中有数,合理的扩缩容。
在可用性指标下,实现最大的承载,我的相关配置是什么?
那在知道了在系统满足了可用性的条件下,最大的承载能力。
我们还需要知道在满足了最大承载能力下我们系统的各项配置是什么。
这可能会包括:JVM配置、DB配置、Redis配置、各类连接池配置等等。
疯狂的流量,疯狂的加实例
最后就是扩展性,上面的指标都是只针对单机而言,在单机情况下的指标,很可能并不能随着机器的增加而线性增加,这时候就需要我们了解:
上面我们主要讲了系统的各项指标,和我们应该了解我们系统的哪些方面,只有在对系统已经十分了解的情况下。
才可以有效的、针对性的对我们的系统进行优化操作,才可以准确的衡量我们的优化效果,而不是靠玄学来做优化。
后面我们会继续讲 怎么来确定我们的优化手段、以及一些常见的优化手段的案例。如果感觉对你有用,麻烦点个赞呗~
来源于:https://juejin.im/post/6872891968985399309