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