通常，平均响应时间越短，系统吞吐量越大；平均响应时间越长，系统吞吐量越小。但是，系统吞吐量越大，未必平均响应时间越短。因为在某些情况（例如，不增加任何硬件配置）吞吐量的增大，有时会把平均响应时间作为牺牲，来换取一段时间处理更多的请求。
举个例子：一个理发店，只有一个理发师、一把理发椅子、一张方便客人等待的长凳。理发师一次只能处理一个客户，其他等待的用户显得很不耐烦，外面打算进来理发的人也放弃了在这家店理发的打算……
有一天，理发师有钱了，他多买了2把理发椅子。这样他可以同时给3个人理发：当其中一个人理到一定阶段需要调整或定型的时候，他就转向另外一个客户为其服务，依次类推。这样，他发现一天内他可以理的人数比以前增多了，但是还会有一些后来的客户抱怨等待时间太长。（吞吐量大了，但平均响应时间却长了）
后来，理发师招了2名学徒帮他一起干活。他发现这样一来每天的理发效率增加了将近2倍，而且客户的等待时间也明显减少。但是成本增多了，理发用具、洗发水、发工资，这让他觉得开个理发店也要精打细算。（平均响应时间短了，吞吐量也大了，但是成本却高了）
示例2：
我们可以利用“门”的概念来理解这里面的偏差！
首先，我们假设如下的情况：
共有5个人；
有1扇门；
一个人通过这扇门需要花费1秒的时间；
此时，这扇门的吞吐量为1人/秒。5个人通过这扇门的平均响应时间为（1+2+3+4+5）/5=3秒。
如何才能提高人的通过效率呢？即，如何才能提高门的吞吐量呢？
有两种方法：
（1）减小通过门的时间；
（2）增加门的数量
例如，
（1）将一个人通过门的时间减小为0.5秒，门的吞吐量变成了2人/秒；
（2）增加一个门，门的吞吐量也变成了2人/秒
结果是：
（1）5个人通过改善通过时间的门的平均响应时间为（0.5+1+1.5+2+2.5）/5＝1.5秒；
（2）5个人通过两扇门的平均响应时间为（1+1+2+2+3）/5＝1.8秒
此时，你可以发现，软件开发员改进软件处理并发交易请求的方法有两个，第一种是提高单个请求的处理速率，第二种是增加处理请求的线程的数量；或者是两种方法的组合。但是，不同方法的使用并不代表吞吐量得到了提高，而同时软件典型交易的平均响应时间也获得了相同值的改善。
因此，在性能测试以吞吐量为检测指标的时候，不光要评估吞吐量是否符合了性能指标的要求，同时也必须考虑响应时间是否符合性能指标的要求。
假设，在测试前，规定了吞吐量为大于25笔交易/秒，平均响应时间为小于5秒，在测试后，若实际吞吐量等于27笔交易/秒，不能仅凭这个27笔交易/秒就确定该软件的性能符合要求了，还要看平均响应时间是否符合要求。这时的平均响应时间可能大于5秒。
而如果测试前，规定了在线人数为10000，平均响应时间为小于5秒，在测试后，仅凭实际平均响应时间等于4秒就可以判断该软件的性能符合要求。