日常工作中,我们总是习惯于通过量化的标准去衡量我们对事物的评价,比如美食点评的星级、酒店的星级、每个个人的信用评分等等。而作为一个 Web 工程师,我们也总是在意于我们网站的性能,因为网站的性能会最直接地影响用户的体验。今天要介绍的就是一种同样能够帮助工程师对应用性能进行量化评估的标准 —— Apdex 。
Apdex 全称是 Application Performance Index,是由 Apdex 联盟开放的用于评估应用性能的工业标准。Apdex 联盟起源于 2004 年,由 Peter Sevcik发起。Apdex 标准从用户的角度出发,将对应用响应时间的表现,转为用户对于应用性能的可量化为范围为 0-1 的满意度评价。
术语
Apdex 定义了应用响应时间的最优门槛为T,另外根据应用响应时间结合 T 定义了三种不同的性能表现:
Satisfied(满意):应用响应时间低于或等于 T(T 由性能评估人员根据预期性能要求确定),比如 T 为 1.5s,则一个耗时 1s 的响应结果则可以认为是 satisfied 的。
Tolerating(可容忍):应用响应时间大于 T,但同时小于或等于 4T。假设应用设定的 T 值为 1s,则 4 * 1 = 4 秒极为应用响应时间的容忍上限。
Frustrated(烦躁期):应用响应时间大于 4T。
公式
Apdext = (Satisfied Count + Tolerating Count / 2) / Total Samples
其中 Satisfied Count
就是指定采样时间内响应时间满足 Satisfied
要求的应用响应次数;而 Tolerating Count
就是指定采样时间内响应时间满足 Tolerating
要求的应用响应次数;最后的 Total Samples
就是总的采样次数总数。从公式可以看出,应用的 Apdex 得分与采样持续时间无关,与目标响应时间 T 相关(在采用总数固定的情况下,T 通过影响 Satisfied Count
以及 Tolerating Count
的值间接影响最终的得分)。
举例来说,假设你的应用期待的响应时间能够在 1000 ms 内,在 100 次采样中,有 50 次应用响应时间低于 1000 ms,30 次应用响应时间处于 1000 ms 到 4000 ms( 4 * 1000ms) 之间,剩下 20 次响应时间长于 4000 ms,那么,该应用在 T = 1000ms 的情况下的 Apdex 值为:
(50 + 30 / 2) / 100 = 0.65
Apdex 与 New Relic
在 New Relic 的 APM(Application Performance Management)功能中,就提供了各个维度的 Apdex 统计结果,比如 Server Apdex(服务器性能评分)以及 Browser Apdex(终端用户性能体验评分),如图:
其中可以看到应用服务器在 T=0.5s
的情况下得到的 Apdex 分数为 0.76,而 Browser(Browser 更多的是静态文件加载) 在 T=7s
的情况下得到的 Apdex 分数为 0.94。结合两者可以判断,目前应用到达终端用户性能表现比较优秀(0.94,比较接近最大值 1),但是其中影响总体性能的瓶颈则在于服务器性能(仅仅只有 0.76 分),通过这样的数据,我们就能知道下一步性能优化的方向了——服务器端性能优化。
实际上,上面展示的只是 New Relic 的一种粒度比较粗的针对整个应用的 Apdex 报表,New Relic 同样提供了很多细粒度的 Apdex 数据,比如下面展示的针对具体的请求入口的 Apdex 报表:
这样,通过逐步的细化,我们就可以进一步定位性能瓶颈,通过不断优化 Apdex 评分低的入口逐步提升应用整体性能体验。
Apdex 与 T 值
从公式中其实可以非常明显地看出来,T 值的选择对于最终的 Apdex 值也会有直接影响,越大的 T 值理论上来说会有更大的 Apdex 得分。比如我们可以在 New Relic 中将应用的 Apdex T 值改为 1s,以下是设定过程中看到的原来的值是 0.5s:
而改为 1s 后,跟上面同样的采样数据得到的新的平均 Apdex 值则高于原来的 0.76。
所以,在对应用性能进行评估的时候,首先需要确保结合应用具体情况设定一个相对合理的 T 值,太大的 T 值会导致过于乐观的 Apdex 值,但是太小的 T 值又会造成过于严苛的性能要求,最终可能导致过度的性能优化。
所以,总而言之,抛弃 T 值谈 Apdex 得分,都是耍流氓!
Apdex 值一定要做到 1 吗?
Apdex 公式计算能够得到的最大值就是 1,表示应用“可能”能够令所有用户对应用性能感到满意。但是, Apdex = 1 可以只是一个不断优化的方向,却不一定是要成为优化的目标,具体根据项目实际情况确定,毕竟,优化本身也需要成本投入,不需要为了极致的性能而投入过多的成本。
参考资料以及推荐链接
文章在我的 blog 上的地址是: http://martin91.github.io/blog/2015/03/28/the-correct-way-to-metric-server-response-time/
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。