【高并发】面试官:性能优化有哪些衡量指标?需要注意什么?

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

面试场景

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

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

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

微信图片_20211119155138.jpg

衡量指标

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

微信图片_20211119155148.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也是要进行优化的。

正确性

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

优化需要注意的问题

image.gif

  • 除非必要,一开始不要优化(尤其是开发阶段)
  • 有些优化准则已经过时,需要考虑当下的软硬件环境(不要墨守成规)
  • 不要过分强调某些系统级指标,如cache 命中率,而应该聚焦性能瓶颈点
  • 不盲从,测试、找到系统的性能瓶颈,再确定优化手段
  • 注意权衡优化的成本和收益(有些优化可能需要现有架构做出调整、增加开发/运维成本)
  • 优化的目标是用户体验、降低硬件成本(降低集群规模、不依赖单机高性能)
  • 测试环境的优化手段未必对生产环境有效(优化需要针对真实情况)
相关文章
|
SQL 关系型数据库 MySQL
MYSQL-SQL语句性能优化策略以及面试题
MYSQL-SQL语句性能优化策略以及面试题
316 1
|
测试技术 Android开发
Android开发规范,性能优化,Android面试2024
Android开发规范,性能优化,Android面试2024
|
架构师 Java 测试技术
一文搞透高并发指标(QPS、TPS、吞吐量等)
详解高并发场景下的QPS、TPS、RT及吞吐量等关键性能指标,帮助理解系统性能评估的核心概念。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
一文搞透高并发指标(QPS、TPS、吞吐量等)
|
SQL 缓存 监控
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
本文详细解析了数据库、缓存、异步处理和Web性能优化四大策略,系统性能优化必知必备,大厂面试高频。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
|
NoSQL Java Redis
京东双十一高并发场景下的分布式锁性能优化
【10月更文挑战第20天】在电商领域,尤其是像京东双十一这样的大促活动,系统需要处理极高的并发请求。这些请求往往涉及库存的查询和更新,如果处理不当,很容易出现库存超卖、数据不一致等问题。
378 1
|
存储 缓存 网络协议
5个Android性能优化相关的深度面试题
本文涵盖五个Android面试题及其解答,包括优化应用启动速度、内存泄漏的检测与解决、UI渲染性能优化、减少内存抖动和内存溢出、优化网络请求性能。每个问题都提供了详细的解答和示例代码。
332 2
|
并行计算 算法 搜索推荐
探索Go语言的高并发编程与性能优化
【10月更文挑战第10天】探索Go语言的高并发编程与性能优化
|
缓存 JSON 网络协议
Android面试题:App性能优化之电量优化和网络优化
这篇文章讨论了Android应用的电量和网络优化。电量优化涉及Doze和Standby模式,其中应用可能需要通过用户白名单或电池广播来适应限制。Battery Historian和Android Studio的Energy Profile是电量分析工具。建议减少不必要的操作,延迟非关键任务,合并网络请求。网络优化包括HTTPDNS减少DNS解析延迟,Keep-Alive复用连接,HTTP/2实现多路复用,以及使用protobuf和gzip压缩数据。其他策略如使用WebP图像格式,按网络质量提供不同分辨率的图片,以及启用HTTP缓存也是有效手段。
228 9
|
算法 Java API
Android性能优化面试题经典之ANR的分析和优化
Android ANR发生于应用无法在限定时间内响应用户输入或完成操作。主要条件包括:输入超时(5秒)、广播超时(前台10秒/后台60秒)、服务超时及ContentProvider超时。常见原因有网络、数据库、文件操作、计算任务、UI渲染、锁等待、ContentProvider和BroadcastReceiver的不当使用。分析ANR可借助logcat和traces.txt。主线程执行生命周期回调、Service、BroadcastReceiver等,避免主线程耗时操作
430 3
|
存储 监控 固态存储
【性能突破】揭秘!如何让您的数据库在高并发风暴中稳如磐石——一场关于WAL写入性能优化的实战之旅,不容错过的技术盛宴!
【8月更文挑战第21天】在高并发环境下,数据库面临极大挑战,特别是采用Write-Ahead Logging (WAL)的日志机制。本文通过一个在线交易系统的案例,分析了WAL写入性能瓶颈,并提出优化方案:理解WAL流程;分析磁盘I/O瓶颈、缓冲区设置与同步策略;通过增大WAL缓冲区、使用SSD及调整同步策略来优化;最后通过测试验证改进效果,总结出一套综合优化方法。
338 0

热门文章

最新文章