image
还在用平均响应时间衡量你的业务KPI？
看看新的指标吧~
关于性能
- 作为互联网后端大军的一员，除了应对日常的各种需求工作，同时还要有效的保障自己手里的服务质量，如何衡量服务质量的优劣（SLA），目前有常见的几种方式：
1. MTBF
-
即平均无故障时间，也就是常见的N个9问题，如5个9的可用性，全年可宕机时间就是5分钟，详见下图，这里不做讨论：
image
2. 性能指标
- 提到性能指标，不得不提的两个细节指标就是QPS（或者TPS）和响应时间：
初出茅庐的‘IT菜鸟们’，往往在接触后端服务的时候，会一味的盯着QPS，一直致力于把单机性能压榨到极限，妄图获得一个高QPS的快感
-
但凡有一定工作经验的人，都知道，不考虑响应时间的QPS，就是耍流氓：
- 还记得双11，你排队却无法支付的尴尬时刻么？
- 还记得在某06网站抢票，以及大学抢选修课时候，怎么点击都没有响应的窘境么？
-
这一切都是下面这个图所示：
- 当吞吞量无限增加（用户无限涌入），会导致响应时间（页面不是不响应，而是慢成天位数字）几何倍增加
响应时间与吞吐量 任何做过后端数据库运维、以及有丰富的后端接口开发经验的人，都明白，只有在保证响应时间可用的情况下，追求吞吐量才是有价值的
关于上面的细节不做讨论，有兴趣“排队论、利特尔法则了解一下”~
响应时间的探讨
随着高速网络、移动网络的兴起，用户被日渐宠坏，你的网站响应时间比别人多1秒，用户都可能接受不了
因此，大多数互联网技术人员，都会对各自服务的响应时间进行实时监控
-
于是乎，大部分人使用了各种时间序列数据库，X轴拉一个时间，Y轴拉一个平均响应时间，完事~
image 真的完事了么？
一个平均响应时间就足以表达出你的服务质量了么？
-
比较professional的，会增加如下指标：
- “90% 99% 99.9%响应时间了解一下”
- “中位数响应时间了解一下”
- “方差、标准差，数据波动，了解一下”
imageimage
- But，今天，我们不介绍这些指标（必经知道的人太多了，不足以显出我们的智(zhuang)慧(bi)）
image
Apdex
是什么？
- 举个例子，沪深三百、道琼斯指数，这些指标是用来衡量股市好坏的指标，原则上讲，你不需要了解所有几百几千支股票的细节，就可以从这些指数上来看出股市行情的好坏
- Apdex就是性能的指数
有啥用？
- 假如你提供的是CDN图片加速服务，你的服务质量标准是200ms（99.9%的用户响应时间在此范围内）
- 假如你的同事，提供的是后端接口服务，SLA定在了50ms以内
- 年底了，老板来看你们的KPI完成了没有
- 请问两个绝对指标不一样的业务，怎么去PK？
- 有了Apdex就可以很好的解决这个问题
怎么算？
很简单
-
假设你的服务标准是200ms，你认为，
- 用户访问在<200的情况下，用户很开心
- 200-1000ms的情况下，勉强可以忍受
- 超过1000ms的情况下，不能接受，用户就不看了
- 那么这个时刻的计算方式如下：
- (满意用户数+可忍受用户数/2)/总的样本数
- 即
image
举例
- 100个用户
- 目标3秒，3-12秒是可忍受
-
其中60个用户低于3秒，30个用户3-12之间，剩余10个在12秒以上，那么：
image - 0.75就是这个服务在这一时刻的性能指数
Apdex怎么来的？
Apdex是国外几家公司一起提出的性能监控指标，并且已经形成了一个联盟组织：http://www.apdex.org/index.html
国外的一家专做APM的公司New Relic对Apdex有比较详细的描述：https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measuring-user-satisfaction
怎么实践？
- 说了这么多，怎么用呢？
- 这个指标的含义真的是太简单、太利于理解了，简单到一条SQL就可以搞定：
- 假如你是Web服务，已经有明确的响应时间范围指标了
- 又假如你用了某个时间序列存储数据库，把每条响应时间的原始数据都记录下来了，于是乎，你只需要：
- 按照时间戳进行聚合
- 每次聚合，计算一下满足RT的有多少，忍受RT的有多少， 总共有多少？
- 什么，不知道SQL怎么写？好吧，看这里
# 以500-2000作为参考指标
SELECT
ts,
((sum(url_rt < 500) + (sum((url_rt >= 500) AND (url_rt <= 2000)) * 0.25)) / count(*)) * 100 AS Apdex
FROM table
GROUP BY ts
ORDER BY ts
- 什么？SQL还能这么写?😀
- 我们使用的是ClickHouse作为APM数据的后端存储，这是一个非常易用、超高性能、支持SQL的分析性数据仓库
- 某业务的原始日志会直接打入ClickHouse，不做聚合
- 使用上述的一条SQL，就可以拿到某个业务的Apdex指标
image
总结
- APM是一个非常复杂的事情，涉及到了后端运维、架构、大数据，以及数据分析等多个领域的交叉结合
- 任何APM、监控等，目的都是为了最终用户的满意程度(End user experience)，因此，只看单一指标、只看平均响应时间，就是耍流氓
