对于一些初学者来说，会因为自己的学艺不精，对jmeter性能测试的机理不够了解，而导致一些理解偏差。比如说将聚合报告上的吐吞率当做服务器的最大吞吐率，而在实际中由于网络带宽原因，本地测试机上测试出的最大吞吐率会可能会远远小于服务器的最大吞吐率。所以本节我将讲述网络带宽是如何影响我们测试数据的，并给出示例和详细的解释。

正文

什么是吞吐率？
       吞吐率TPS（Transaction per second）是指一个业务系统在单位时间内处理事务的总量。在事务的定义中可以是一个请求或者多个请求的集合，在Jmeter中可以用事务控制器（Transaction Controller）来控制。在资源有限的情况下每个系统都会有一个最大的吞吐率。在Jmeter中并发数和吞吐率有一定关系如下图。

       从图中可以直观的看到，吞吐率会随着并发数提高的时候增长，但在用户数提高到一定程度时吞吐率不变，此时为系统的最大吞吐率（如例子中100/s）。当我们在本地下测出最大吞吐率时，我们往往会忽略我们本地网络带宽的原因，把测试出的数据当成系统最大的吞吐率。为什么这样说呢？请看下面示例，我将分三种不同网络环境下（WiFi、手机热点、云服务器）以访问百度为例进行测试。这个图的原理我将在系列中之后的章节中分析。

本地WiFi网络下测试结果

200 * 1 * 100（200线程1s内启动循环100次，下同理）

400 * 1 * 100

600 * 1 * 100

800 * 1 * 100

1000 * 1 * 100

从以上个测试结果分析出本地WiFi环境下最大吞吐率约为320/s。

本地手机热点下网络下测试结果

200 * 1 * 1min（200线程1s内启动循环1分钟）

400 * 1 * 1min

600 * 1 * 1min

800 * 1 * 1min

从以上测试结果分析出手机热点网络环境下最大吞吐率约约为130/s

固定带宽（8M/s）网络下测试结果

【这个图以后再补】

结论

       通过比较以上三种网络环境下的测试结果我们发现

1. 三种不同网络环境下测试出最大的吞吐率不一致
2. 三种不同网路环境下测试出的最大吞吐率也不是百度的最大吞吐率
3. 某些网络环境下高并发比低并发的吞吐率低

       其实拿访问百度主页做测试也不太恰当，应为它的吞吐率用单机是不可能测试出来的。如果你们想验证一下上面的例子可以找一个类似于自己服务器上post请求的接口。不同网络环境下，因为带宽不同，所以我们本地测试机处理的请求也不同。比如现在本地带宽为2M，请求一次需要5kb，那每秒只能发送400个请求；但是如果本地现在带宽为4M，那每秒就能800个请求；但服务器的最大吞吐率为1000/s。 所以在性能测试中，我们一定要注意一项指标就是服务器CPU，来观测服务器资源使用和处理事务能力的关系。在本地网络环境测试中，由于网络不稳定所以可能会导致高并发比低并发的吞吐率低，为了规避这些不可控因素建议大家将测试环境放到云服务器上，这样网络会较为稳定，而且带宽也可以按需调整。

       本节主要想表达的结论是：因为在请求过程中向服务器单位时间发送请求的数量并未达到最大吞吐率的值，所以我们不能把测出的值当做真实系统最大的吞吐率。除了带宽会对单位时间发送请求数量约束外，测试环境的CPU也会带来影响。因为每个线程默认为2M的空间，32位系统Java进程只能占2G，约1000个线程可用。64位系统无线程限制但会取决于CPU的大小。在测试过程中我们一定要查看测试机的资源使用情况，确定我们测试出的瓶颈源自服务器，而不是我们自己的测试机。希望可以解除你对测试数据中的一些疑惑，若有疑问请评论留言，谢谢。