性能度量

今天黎叔请大家喝咖啡的时候谈到性能是目前优先级最高的问题。那我们怎么度量系统的性能呢？

首先，对于用户来说，最直观的感受是系统响应时间，就是从用户触发一个操作开始到操作成功所经历的时间。比如用户使用某一功能时，它的响应时间如下：

0.5s, 0.5s, 0.5s, 0.5s, 8s

那么系统的响应时间应该用平均时间，即2s来表示吗？显然8s是一个少数异常情况才会出现的噪音，在80%的情况下系统的响应时间是0.5s，0.5s比8s更能反应系统的真实响应时间。

比如有一家金融公司是这么要求响应时间的：

99.9%的响应时间必需在1ms之内，平均响应时间在1ms以内，100%的请求成功。

除了响应时间，我们还要看系统的吞吐量，比如在只有10个并发用户的时候，系统的响应时间是0.5s，但是如果并发用户数增加到100时，系统就会变得很慢，说明系统的吞吐量是小于100的。

吞吐量除了要和正常的响应时间挂钩，还要和正确率挂钩，假设你号称系统的吞吐量在1000个并发用户，但是在1000个并发用户时，40%用户请求都失败了，说明系统的吞吐量并没有达到1000，吞吐量必须是在100%的成功率下面计算出来的。

还有一个很常见的性能度量就是资源利用率，比如CPU，内存和磁盘空间和IO等。

喝咖啡的时候还提到性能可视化，希望能有一个大屏能实时监控系统的性能，比如：

1. 目前Top 10常用功能的响应时间，后台消息处理的响应时间。
2. 当前并发用户数、每秒请求数、进出的消息数量。
3. 当前正在执行的慢功能（比如超过1分钟的还在执行的功能），因为很多系统问题是因为慢功能导致的。
4. 失败的前台请求或者后台处理。
5. 应用服务器的资源利用情况和节点死活情况。
6. 数据库服务器的资源利用情况。

希望今天写的今年能变为现实。