【性能优化(上)】你真的了解你的系统吗?

1,986 阅读5分钟

前言

当我们的系统达到了一定的量级/用户之后,或多或少都会接触到性能优化相关的内容,大家可能根据自己的经验,都有自己的一套优化手法。但是可能还有很多人面对性能问题时,可能无从下手。或者在性能优化的过程中,会踩不少坑。 所以这个性能优化系列主要会通过几个方面的内容,让大家对于整个性能优化的过程有一个整体的了解,并且通过一些常见的优化手段和案例,让大家少走一点弯路。

性能衡量指标

大家都没有过这样的时候:

我觉得这样优化肯定有效果!  
我觉得当前的系统应该可以抗住明天的流量?
改了这个配置应该可以提升一些性能吧?

我觉得、我感觉、不管有没有用,做了再说。但是我们在发布了一个优化版本之后,要通过什么方式去验证它的效果呢?

优化不是凭感觉,需要有实际的数据作为支撑

我们每次优化,都需要有实际的数据来做验证,根据数据来调整我们的优化方向和内容。那哪些数据可以做为性能指标呢?

系统

系统性能指标主要是针对我们的应用的整体情况,主要包括:RT(请求响应时间)、QPS、TPS、吞吐量等

中间件

中间件主要包括我们的依赖的虚拟机、外部系统或框架,可能包括:JVM、DB、Redis等

资源

资源就是我们系统依赖的容器、虚拟机或物理机上的三大马车:CPU、IO、MEMORY

稳定性

稳定性主要包括我们系统的SLA、宕机恢复时间等

可扩展性

可扩展性主要关注系统是否是可以线性扩展的

你对你的系统了如指掌吗?

知道了上面这些指标后,我们可以想一下,我们对自己的系统是否真的了解呢? 下面两个问题大家可以尝试回答一下:

1. 知道你的系统现在可以承受多大的用户量或访问量吗?
2. 如果明天你的服务访问量会增加10倍,知道要怎么扩容吗?

如果你无法回答这两个问题,那可能下面的内容会对你有一点帮助。

我需要了解什么

定义自己系统的可用指标

在什么指标下,我的系统是可用的

最基础的一点是,我们最少需要知道在什么样的指标下,我的系统是可用的(可正常对外提供服务)

举个栗子,当我的系统满足以下指标时,它才是可用的:

||| |-|-|- |CPU| 使用率 < 70% | |RT |99线 < 40ms,95线 < 20ms,90线 < 5ms | |内存 | 使用率 < 70% | |GC | FullGC < 1次/天 MiniorGC < 5次/分钟 | |...... ||

上面举例不代表实际情况,大家需要根据自己系统的实际情况来制定对应的指标

在可用性指标下,我的系统承载能力是多少

只要在这个量级以下,来多少都不怕

在满足了上面的可用性指标的情况下,我们还需要确定在常规的流量比例下,我们系统的极限在哪里(QPS、TPS、吞吐量的值)。

比如在可用性指标下,某个系统的 MAX(QPS) = 10W、MAX(TPS) = 8W、MAX(Throughput) = 13W。我们只有知道了系统的可用极限,才能够在需要扩容的时候做到心中有数,合理的扩缩容。

系统配置

在可用性指标下,实现最大的承载,我的相关配置是什么?

那在知道了在系统满足了可用性的条件下,最大的承载能力,我们还需要知道在满足了最大承载能力下我们系统的各项配置是什么,这可能会包括:JVM配置、DB配置、Redis配置、各类连接池配置等等。

扩展性

疯狂的流量,疯狂的加实例

最后就是扩展性,上面的指标都是只针对单机而言,在单机情况下的指标,很可能并不能随着机器的增加而线性增加,这时候就需要我们了解:

  1. 系统瓶颈,我们需要知道系统瓶颈在哪,当进行扩容时,需要考虑瓶颈,并且当我们在优化时应该第一项优化
  2. 依赖服务的承载能力,包括DB、Redis等,我们的服务在扩容时,下面的基础设施是不是也需要跟着扩容,该如何扩
  3. 代码逻辑中是否存在单点,比如分布式锁之类的,在扩容时也是需要考虑的,在优化时也需要第一时间优化

结语

上面我们主要讲了系统的各项指标,和我们应该了解我们系统的哪些方面,只有在对系统已经十分了解的情况下,才可以有效的、针对性的对我们的系统进行优化操作,才可以准确的衡量我们的优化效果,而不是靠玄学来做优化。后面我们会继续讲 怎么来确定我们的优化手段、以及一些常见的优化手段的案例。如果感觉对你有用,麻烦点个赞呗~