经常会碰到有人说某某server的性能极高，能并发成百上千的请求云云。 我觉得这里很重要一点，就是要区分**延迟(latency)和吞吐量(throughput)**之间的区别，有时候两者还是矛盾的。延迟是指一个动作从发起到完成花了多长时间，吞吐量是指一段时间内处理了多少工作。
我觉得举个银行柜台的例子，可以类比一下。把银行柜台比作一个接受处理请求的系统，把每一个排队的顾客看作一个请求。如果这样比较的话，那么延迟(latency)就是一个顾客从到柜台窗口到离开柜台服务用的是时间；而吞吐量(throughput)则是每小时这个银行能处理多少个顾客。让我们来考虑两个相反的例子：
低延迟(latency)加低吞吐量(throughput)是个什么情况呢？那就是银行的柜员个个都是手脚勤快，处理每个顾客都是分分钟的事情，这就是低延迟。但是呢，不幸的是这个银行的员工比较少，开的柜台窗口比较少。所以就算这些柜员再能干，他们每小时处理的顾客也是比较有限的。在这种情况下，如果客户不多的话，用户体验还是不错的。因为一到银行就能办业务，办得又快。问题是，顾客多的时候，低吞吐量的瓶颈就明显了。
类比到程序，就是这个程序很快，但是并发差。例如，有个servlet，做一个很简单的工作，每次HTTP请求反应极快。但是，一旦有很多个HTTP请求一起来，那么处理完所有这些请求就要费很长时间。
我们在考虑相反的情形：高延迟(latency)加高吞吐量(throughput)。 这里的高延迟(latency)就是对应每个柜员都是干活慢慢吞吞。但是呢，好在这个银行的柜员多啊，譬如同时开了10个窗口在处理业务。结果就是：每个顾客都要用好久，但是在一段时间内，总的处理顾客数还是很高。
类比到程序，就是这个程序慢，但是并发好。还是servlet的例子，让这个servlet做很费时间的操作。但是呢，这个servlet能同时接受很多的HTTP请求。这就是个高延迟加高吞吐量的系统。
矛盾在于有限的资源。银行的资源在于人力，柜员是有限。如果柜员像计算机那样多线程工作的话，假设要求每个柜员低延迟，那么他势必专注于每个正在服务的顾客。这样就不可能同时服务很多顾客。如果要让他同时服务于很多顾客，那么每个顾客的服务时间就会变长。
回到开头，咱经常会碰到有人说某某server的性能极高，能并发成百上千的请求云云。那我就问，那它的响应延迟是不是很慢啊？说到底，计算机就这点有限的计算能力。让它跑得即要快又要多，那是不可能的。