理解Latency和Throughput

    Latency，中文译做延迟。Throughput，中文译做吞吐量。它们是衡量软件系统的最多见的两个指标。

    延迟通常包括单向延迟（One-way Latency）和往返延迟（Round Trip Latency），实际测量时通常取往返延迟。它的单位通常是ms、s、min、h等。

    而吞吐量通常指至关一段时间内测量出来的系统单位时间处理的任务数或事务数（TPS）。注意“至关一段时间”，不是几秒，而多是十几分钟、半个小时、一天、几周甚至几月。它的单位通常是TPS、每单位时间写入磁盘的字节数等。

    思考一个问题：

低延迟必定意味着高吞吐量吗？若是不是，试举出反例。

    假若有一个网站系统，客户端每次请求网站服务端，网络传输时间（包括往返）为 200ms，服务端处理请求为10ms。那么若是是同步请求，则延迟为210ms。此时若是提升网络传输速度，好比提升到100ms，那么延迟为110ms。这种状况减小延迟彷佛确实能够必定程度提升吞吐量，缘由主要在于：系统性能瓶颈不在于服务端处理速度，而在于网络传输速度。

    继续假设将同步请求改成异步请求，那么如今延迟为100ms，延迟下降了，但吞吐量保持不变。因此这是一个反例。

    除了上面这个反例外，还有一个更生动的反例：

火车、飞机运煤：
从山西到广州运煤，一列火车100小时（包括往返）能够运输10000t煤，而一架飞机20小时（包括往返）能够运输100t煤

    显然飞机运煤的延迟明显低于火车运煤，但若是测试运10000t煤，则火车运煤的吞吐量远高于飞机：

• 火车运煤的吞吐量为100t/小时
• 飞机运煤的吞吐量为5t/小时

    咱们能够将上面的运煤场景类比软件系统，火车、飞机运煤能够比做Web服务器处理请求，好比Apache和Nginx。在并发请求数不高时，好比10000（我假设的）如下时，也许Apache的吞吐量可能优于Nginx，但在大于10000时Apache的吞吐量就开始急剧降低，而Nginx的吞吐量相对以前比较稳定。因此比较Web服务器的吞吐量时，必须观察在并发请求数逐渐递增状况下它们各自的表现。

    根据延迟和吞吐量咱们还能够计算并发度（Concurrency），公式以下：

并发度 = 吞吐量 * 延迟

    好比一个任务的处理花费1ms，吞吐量为1000tps，那么并发度就等于1/1000*1000=1，能够得出任务处理线程模型是单线程模型。

    又好比一个HDD磁盘的延迟为8ms，但吞吐量能够达到每秒钟写40MB，那么每次磁盘寻道能够写入的数据量为(40*10^6) * (8*10^-3)B = 320,000B = 320KB。 

参考资料：

http://vanillajava.blogspot.com/2012/04/what-is-latency-throughput-and-degree.html

http://queue.acm.org/detail.cfm?id=1854041