【高并发】面试官：性能优化有哪些衡量指标？需要注意什么？
写在前面
最近，很多小伙伴都在说，我没做过性能优化的工作，在公司只是做些CRUD的工作，接触不到性能优化相关的工作。现在出去找工作面试的时候，面试官总是问些很***钻的问题来为难我，很多我都不会啊！那怎么办呢？那我就专门写一些与高并发系统相关的面试容易问到的问题吧。今天，我们就来说说在高并发场景下做性能优化有哪些衡量标准，以及做优化时需要注意哪些问题。
面试场景
面试官：平时工作中有没有做过一些性能优化相关的工作呢？
首先，我们来分析下面试官的这个问题。其实，以我本人招聘面试的经验来说，如果面试官问出了这样的一个问题。本质上不只是想让面试者简单的回答：做过或者没做过。而是想通过这个简单的问题来考察下面试者的思考能力和对于问题的理解能力。面试官本质上是想让面试者通过这个问题，讲述一下自己做性能优化相关工作的经验、以及对于性能优化工作的一些理论的理解，比如就包括：性能优化的衡量指标，期间需要注意的问题等等。
如果面试者在面试过程中，不能充分理解面试官的意图，回答问题时，像挤牙膏一样，挤点出点，那么，大多数情况下，面试官就会认为这个人没啥性能优化的经验。此时，面试者就会在面试官心理的印象大打折扣，面试结果就有非常大的概率凉凉了。
衡量指标
对于性能优化来说，衡量的指标有很多，大体上可以分为：性能指标、响应时间、并发量、秒开率和正确性等。我们可以使用下图来表示这些衡量指标。
接下来，我们就分别说明下这些衡量指标。
性能指标
性能指标又可以包含：吞吐量和响应速度。我们平时所说的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也是要进行优化的。
正确性
正确性说的是无论我们以何种方式，何种手段对应用进行优化，优化后的交互数据结果必须是正确的。不能出现优化前性能比较低，数据正确，而优化后性能比较高，反而数据不正确的现象。
优化需要注意的问题
- 除非必要,一开始不要优化(尤其是开发阶段)
- 有些优化准则已经过时,需要考虑当下的软硬件环境(不要墨守成规)
- 不要过分强调某些系统级指标,如cache 命中率,而应该聚焦性能瓶颈点
- 不盲从，测试、找到系统的性能瓶颈，再确定优化手段
- 注意权衡优化的成本和收益（有些优化可能需要现有架构做出调整、增加开发/运维成本）
- 优化的目标是用户体验、降低硬件成本（降低集群规模、不依赖单机高性能）
- 测试环境的优化手段未必对生产环境有效（优化需要针对真实情况）
重磅福利
关注「 冰河技术 」微信公众号，后台回复 “设计模式” 关键字领取《深入浅出Java 23种设计模式》PDF文档。回复“Java8”关键字领取《Java8新特性教程》PDF文档。回复“限流”关键字获取《亿级流量下的分布式限流解决方案》PDF文档，三本PDF均是由冰河原创并整理的超硬核教程，面试必备！！
好了，今天就聊到这儿吧！别忘了点个赞，给个在看和转发，让更多的人看到，一起学习，一起进步！！
写在最后
如果你觉得冰河写的还不错，请微信搜索并关注「 冰河技术 」微信公众号，跟冰河学习高并发、分布式、微服务、大数据、互联网和云原生技术，「 冰河技术 」微信公众号更新了大量技术专题，每一篇技术文章干货满满！不少读者已经通过阅读「 冰河技术 」微信公众号文章，吊打面试官，成功跳槽到大厂；也有不少读者实现了技术上的飞跃，成为公司的技术骨干！如果你也想像他们一样提升自己的能力，实现技术能力的飞跃，进大厂，升职加薪，那就关注「 冰河技术 」微信公众号吧，每天更新超硬核技术干货，让你对如何提升技术能力不再迷茫！
