面试官：平时工作中有没有做过一些性能优化相关的工作呢？
在面试中你可能会遇到面试官问你，小老弟，你在平时日常工作中有咩有进行过性能优化啊！
这个时候可能你可能都心里MMP了： 公司里那么多大佬。哪能轮得到我来优化…
但是还是得满怀笑容得说：“ 嗯嗯 ，这个有的…"
你可能懂得性能调优主要有： 服务器句柄调优、线程池调优、JVM调优、数据库优化、容器调优、网络请求优化等。。。但是却不知道从何说起，一说就开始没头没脑，只能等面试官问一点，说一点就和挤牙膏一样。
其实，以我本人面试经验来说，如果面试官问出了这样的一个问题。本质上不只是想让面试者简单的回答：做过或者没做过。而是想通过这个简单的问题来考察下面试者的思考能力和对于问题的理解能力。面试官本质上是想让面试者通过这个问题，讲述一下自己做性能优化相关工作的经验、以及对于性能优化工作的一些理论的理解，比如就包括：性能优化的衡量指标，期间需要注意的问题等等。
调优衡量标准
对于系统性能优化来说，衡量标准大概可以分为：
- 性能指标
- 并发量
- 响应时间
- 秒开率
- 准确性
接下来就针对这些指标逐一介绍
性能指标
一般来说，性能指标主要包含吞吐量和响应时间。我们平时常说的QPS、TPS、HPS的等就可以归纳为吞吐量。
有很多小伙伴可能对于QPS、TPS和HPS等不太了解，我们先来说下这几个字母的含义。
QPS 即 Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数
TPS 即 Transactions Per Second 的缩写，每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。
HPS 即 Hits per Second ,每秒http的请求数量，即每秒点击次数
RPS 代表吞吐率，即 Requests Per Second 的缩写。吞吐率是服务器并发处理能力的量化描述
PV 即 Page View, 即页面浏览量
DAU 即 Day Acitivity User 日活跃用户数，反映网站、互联网应用或网络游戏的运营情况的统计指标
MAU 即 monthly active user 月活跃用户
平时我们在做优化工作的时候，要明确系统优化的目标。比如说，我们是为了提高系统的吞吐量? 还是为了提高系统的响应速度。
举个例子，我们的程序中存在一些数据库或者缓存的批量操作，虽然在数据的读取上，响应速度下降了，但是我们优化的目标就是吞吐量，只要我们优化后系统的整体吞吐量明显上升了，那这也是提升了程序的性能。所以说，优化性能并不一定只是提高系统的响应速度或吞吐量，而且在吞吐量和响应速等相关指标之间找到一个平衡点， 使得有限的服务器资源给用户带来更好的服务体验.
响应时间
一般来说，度量性能的指标是系统接口的响应时间，但是单次的响应时间是没有意义的，我们需要知道一段时间的性能情况是怎么样的。 所以，我们需要收集这段时间的响应时间数据，然后根据一些统计方法计算特征值，这些特征值就能代表这段时间的性能情况。 常见的方法有以下几类。
平均响应时间
顾名思义，平均值就是一段时间内所有请求的响应时间数据相加，再除以总请求数。通常平均响应时间体现的是服务接口的平均处理能力。但它敏感度比较差，如果这段时间有少量慢请求时，在平均值上并不能如实地反应性能波动的问题。
举个例子，假设我们30s内有10000次请求，每次请求响应时间都为1ms，那么这段时间响应平均时间也是1ms.
这时，当其中的100个请求响应时间变为了100ms, 那么整体响应时间 变为 （100100+99001)/10000 =1.99ms。
虽然平均值增加了才0.9ms，但是还是有1% 的请求（100/10000）的响应时间已经变慢了100倍。 所以平均值只能最为一个度量标准参考。
分位值
分位数就是我们在优化的时候，圈定一个时间范围，把每次请求的耗时加入一个列表中，然后按照从小到大的顺序将这些时间进行排序。
比如 90 分位、95 分位、75 分位。以 90 分位为例，我们把这段时间请求的响应时间从小到大排序，假如一共有 100 个请求，那么排在第 90 位的响应时间就是 90 分位值。分位值排除了偶发极慢请求对于数据的影响，能够很好地反应这段时间的性能情况，分位值越大，对于慢请求的影响就越敏感。
在我来看，分位值是最适合作为时间段内，响应时间值来使用的，在实际工作中也应用最多。除此之外，平均值也可以作为一个参考值来使用。
并发量
并发量指的是系统能够同时处理的请求数量，反映的是系统的负载能力。我们在对高并发系统进行优化的时候，往往也会在并发量上进行调优，调优方式也是多种多样的，目的就是提高系统同时处理请求的能力。
秒开率
秒开率主要针对的是前端网页或者移动端APP来说的，如果一个前端网页或者APP能够在1秒内很平滑的打开，尤其是首页的加载。此时用户使用起来就非常的丝滑，如果超过3秒甚至更长的时间，用户就有可能会直接退出前端网页或者APP不再使用。所以，在高并发场景下优化程序，不只要对后端程序进行优化，对于前端和APP也是要进行优化的。
准确性
无论我们以何种方式，何种手段对应用进行优化，优化后的交互数据结果必须是准确的。不能出现优化前性能比较低，数据正确，而优化后性能比较高，反而数据不正确的现象。
性能优化需要主要的问题
注意点
不要过早优化 ，除非必要,一开始不要优化(尤其是开发阶段)
不用墨守成规，有些优化准则已经过时,需要考虑当下的软硬件环境
聚焦性能瓶颈点，不要过分强调某些系统级指标,如cache 命中率,而应该聚焦性能瓶颈点
不盲从，测试、找到系统的性能瓶颈，再确定优化手段
注意权衡优化的成本和收益（有些优化可能需要现有架构做出调整、增加开发/运维成本）
明确目标，优化的目标是用户体验、降低硬件成本（降低集群规模、不依赖单机高性能）
优化需要针对真实情况，测试环境的优化手段未必对生产环境有效，还是得按照实际场景
有兴趣的老爷，可以关注我的公众号【一起收破烂】，回复【006】获取2021最新java面试资料以及简历模型120套哦~
