系统性能优化的关键指标(yyds)!!!

简介: 最近,很多小伙伴都在说,我没做过性能优化的工作,在公司只是做些CRUD的工作,接触不到性能优化相关的工作。现在出去找工作面试的时候,面试官总是问些很刁钻的问题来为难我,很多我都不会啊!那怎么办呢?那我就专门写一些与高并发系统相关的面试容易问到的问题吧。今天,我们就来说说在高并发场景下做性能优化有哪些衡量标准,以及做优化时需要注意哪些问题。

面试场景

面试官:平时工作中有没有做过一些性能优化相关的工作呢?

首先,我们来分析下面试官的这个问题。其实,以我本人招聘面试的经验来说,如果面试官问出了这样的一个问题。本质上不只是想让面试者简单的回答:做过或者没做过。而是想通过这个简单的问题来考察下面试者的思考能力和对于问题的理解能力。面试官本质上是想让面试者通过这个问题,讲述一下自己做性能优化相关工作的经验、以及对于性能优化工作的一些理论的理解,比如就包括:性能优化的衡量指标,期间需要注意的问题等等。

如果面试者在面试过程中,不能充分理解面试官的意图,回答问题时,像挤牙膏一样,挤点出点,那么,大多数情况下,面试官就会认为这个人没啥性能优化的经验。此时,面试者就会在面试官心理的印象大打折扣,面试结果就有非常大的概率凉凉了。

、.jpg

衡量指标

对于性能优化来说,衡量的指标有很多,大体上可以分为:性能指标、响应时间、并发量、秒开率和正确性等。我们可以使用下图来表示这些衡量指标。

微信图片_20211121154251.jpg

接下来,我们就分别说明下这些衡量指标。

性能指标

性能指标又可以包含:吞吐量和响应速度。我们平时所说的QPS、TPS和HPS等,就可以归结为吞吐量。有很多小伙伴可能对于QPS、TPS和HPS等不太了解,我们先来说下这几个字母的含义。

  • QPS代表的是每秒的查询数量。
  • TPS代表的是每秒事务的数量。
  • HPS代表的是每秒的HTTP请求数量。

这些都是与吞吐量相关的衡量指标。

平时我们在做优化工作的时候,首先要明确需要优化的事项。比如:我们做的优化工作是要提高系统的吞吐量?还是要提升系统的响应速度呢?举一个具体点的例子:比如我们的程序中存在一些数据库或者缓存的批量操作,虽然在数据的读取上,响应速度下降了,但是我们优化的目标就是吞吐量,只要我们优化后系统的整体吞吐量明显上升了,那这也是提升了程序的性能。

所以说,优化性能不只是提升系统的响应速度。

这里,优化性能也并不是一味的优化吞吐量和优化响应速度,而是在吞吐量和响应速度之间找到一个平衡点,使用有限的服务器资源来更好的提升用户体验。

响应时间

对于响应时间来说,有两个非常重要的衡量指标。那就是:平均响应时间和百分位数。

(1)平均响应时间

通常,平均响应时间体现的是服务接口的平均处理能力。计算方式就是把所有的请求所耗费的时间加起来,然后除以请求的次数。举个简单的例子:比如:我们向一个网站发送了5次请求,每次请求所耗费的时间分别为:1ms,2ms,1ms,3ms,2ms,那么,平均响应时间就是(1+2+1+3+2)/ 5 = 1.8ms,所以,平均响应时间就是1.8ms。

平均响应时间这个指标存在一个问题:如果在短时间内请求变得很慢,但很快过去了,此时使用平均响应时间就无法很好的体现出性能的波动问题。

(2)百分位数

百分位数就是我们在优化的时候,圈定一个时间范围,把每次请求的耗时加入一个列表中,然后按照从小到大的顺序将这些时间进行排序。这样,我们取出特定百分位的耗时,这个数字就是 TP 值。

TP值表示的含义就是:超过 N% 的请求都在 X 时间内返回。比如 TP90 = 50ms,意思是超过 90th 的请求,都在 50ms 内返回。

百分位数这个指标也是很重要的,它反映的是应用接口的整体响应情况。

我们一般会将百分位数分为 TP50、TP90、TP95、TP99、TP99.9 等多个段,对高百分位的值要求越高,对系统响应能力的稳定性要求越高。

并发量

并发量指的是系统能够同时处理的请求数量,反映的是系统的负载能力。

我们在对高并发系统进行优化的时候,往往也会在并发量上进行调优,调优方式也是多种多样的,目的就是提高系统同时处理请求的能力。

总体来说,并发量这个指标理解起来还是比较简单的,我就不做过多的描述了。

秒开率

秒开率主要针对的是前端网页或者移动端APP来说的,如果一个前端网页或者APP能够在1秒内很平滑的打开,尤其是首页的加载。此时,用户就会感到前端网页或者APP使用起来很顺畅,如果超过3秒甚至更长的时间,用户就有可能会直接退出前端网页或者APP不再使用。

所以,在高并发场景下优化程序,不只要对后端程序进行优化,对于前端和APP也是要进行优化的。

正确性

正确性说的是无论我们以何种方式,何种手段对应用进行优化,优化后的交互数据结果必须是正确的。不能出现优化前性能比较低,数据正确,而优化后性能比较高,反而数据不正确的现象。

优化需要注意的问题

微信图片_20211121154254.jpg

  • 除非必要,一开始不要优化(尤其是开发阶段)
  • 有些优化准则已经过时,需要考虑当下的软硬件环境(不要墨守成规)
  • 不要过分强调某些系统级指标,如cache 命中率,而应该聚焦性能瓶颈点
  • 不盲从,测试、找到系统的性能瓶颈,再确定优化手段
  • 注意权衡优化的成本和收益(有些优化可能需要现有架构做出调整、增加开发/运维成本)
  • 优化的目标是用户体验、降低硬件成本(降低集群规模、不依赖单机高性能)
  • 测试环境的优化手段未必对生产环境有效(优化需要针对真实情况)
相关文章
|
4月前
|
SQL 缓存 Java
性能优化思路及常用工具及手段问题之watch工具分析的问题如何解决
性能优化思路及常用工具及手段问题之watch工具分析的问题如何解决
|
4月前
|
Arthas 数据采集 测试技术
性能优化思路及常用工具及手段问题之利用工具采集系统热点问题如何解决
性能优化思路及常用工具及手段问题之利用工具采集系统热点问题如何解决
|
存储 关系型数据库 MySQL
深聊性能测试,从入门到放弃之:性能测试技术栈,看完这篇,保证刷新你对性能测试的认知~~
深聊性能测试,从入门到放弃之:性能测试技术栈,看完这篇,保证刷新你对性能测试的认知~~
198 1
|
6月前
|
缓存 小程序 前端开发
小程序 如何做性能优化?
小程序 如何做性能优化?
|
6月前
|
缓存 Java 测试技术
总结|性能优化思路及常用工具及手段
性能优化是降低成本的手段之一,每年大促前业务平台都会组织核心链路上的应用做性能优化,一方面提升系统性能,另外一方面对腐化的代码进行清理。本文结合业务平台性能优化的经验,探讨一下性能优化的思路及常用工具及手段。
75841 1
|
监控 网络协议 Java
【深入了解系统性能优化】「实战技术专题」全方面带你透彻探索服务优化技术方案(系统服务调优)
系统运行缓慢,执行速度较差虽然没有对用户或公司造成实质性的损失,但它从侧面反映出系统在某些方面存在问题。可能需要对系统参数进行优化,或者对系统的设计和交互进行调整,这是后续系统性能优化的一个重要过程。我们将继续努力优化系统,以确保其高效运行和良好性能,以提升用户体验并最大程度地满足业务需求。我们希望通过系统调优的历程,解决当前存在的问题,并不断改进系统的运行,为用户提供更好的服务。
356 0
【深入了解系统性能优化】「实战技术专题」全方面带你透彻探索服务优化技术方案(系统服务调优)
|
监控 数据管理 测试技术
性能测试技术笔记(三):如何设计一个压测平台
对于压测平台,或者说各种测试平台,其实很多同学有个误区就是:平台各种高大上牛逼,但往往忽略了开发和维护以及学习使用平台本身的成本。
性能测试技术笔记(三):如何设计一个压测平台
|
Web App开发 JavaScript 前端开发
当我们进行性能优化,我们在优化什么(LightHouse优化实操)
好的互联网产品不仅仅在功能上要高人一筹,在性能层面也需要出类拔萃,否则金玉其外败絮其中,页面是美轮美奂了,结果首屏半天加载不出来,难免让用户乘兴而来,败兴而归。 幸运的是,前端的性能优化有诸多有迹可循的理论和方法,其中相对权威的,无疑是LightHouse。
当我们进行性能优化,我们在优化什么(LightHouse优化实操)
|
Web App开发 监控 前端开发
前端如何进行网站性能分析及优化性能
前端如何进行网站性能分析及优化性能
下一篇
无影云桌面