分析系统性能的常用指标

系统吞吐量和延迟

系统的吞吐量和延迟是系统最重要的两个指标，很多时候大家都分不清它们之间的区别。

吞吐量是一个系统一定时间内能处理的请求数，一般用qps还表示，意为秒内所能处理的请求数。而延迟是一个请求从发送到返回结果之间消耗的时间，一般用平均延迟，以及最大延迟来衡量

两者衡量一个系统性能的不同方面，没有必然的联系，但是会相互影响。

如果发现延迟比较大，需要分析时间耗费在哪一部分。当压力小的时候的延迟如果很小，但是压力大了以后延迟也变大，那就需要分析系统是不是哪部分资源不足（cpu 内存，如果能将top中所有关于cpu与内存的指标都看明白，我相信找出这两部分的因素是很容易的 网络，磁盘），导致队列阻塞了请求很长时间。如果系统负载都没有问题，相信我，那八成是你程序的处理结果存在问题，某个地方阻塞住了请求，即使系统负载有问题，也可能是你程序的问题，是否真的需要消耗这么多资源？同样的方法适用于分析其他的系统问题

Q：延迟大的系统是否吞吐量一定低？

不一定

Q:吞吐量、延迟和体系结构中用到的带宽、延迟是否同一性质的概念的延伸？

类似

 

同步和异步

同步程序开发通常简单直接，异步程序开发通常需要写回调，各种callback(事情也在慢慢的变好，协程概念正在慢慢的得以应用，将大大建华异步程序开发)

异步带来什么好处？笔者理解就是一句话，计算资源不用再为等待io而消耗资源，从而释放更多资源的潜力

apache跟nginx的区别就是这个道理的验证，apache采用同步的概念，导致很多计算资源在等待io资源，所以吞吐量上不去

异步程序往往采用reactor的模式，对提升系统吞吐量有非常好的帮助

（一些好用的异步库，c++中的libevent ，python中的eventlet，采用协程，是python异步编程首选）

批处理

之前碰到过这样一个问题：从一台控制机上要一天要更新一亿条请求到其他三个机房，到这三个机房的速度死慢，之前的策略是每次更新一条，但是很快发现这样一天下来更新不完全部的数据，怎么办？

控制机到各个机房之间是延迟大，但是带宽不小，所以批量的发数据更新是一个经济的方法，这样就能将延迟分摊到批量数据的每一条上。用redis数据库，其中有pipeline的命令，可以完美的完成这个任务

大家都知道tcp中有慢启动，先发一个包，有应答了下次再发两个，下下次发四个，对于局域网，这是ok的，但是对于广域网延迟大的情况下，这是非常耗时的，所以google有个优化，就是增大慢启动的第一次发包数，也是同样的道理

这些都给如何克服延迟大带来了一些启示

连接数与qps

压测工具中一般会有连接数与qps的选项，这是两个完全不同的概念，需要体会下