你真的会使用Jmeter吗(二)网络带宽影响测试数据 | 您所在的位置:网站首页 › nmon查看网络带宽 › 你真的会使用Jmeter吗(二)网络带宽影响测试数据 |
对于一些初学者来说,会因为自己的学艺不精,对jmeter性能测试的机理不够了解,而导致一些理解偏差。比如说将聚合报告上的吐吞率当做服务器的最大吞吐率,而在实际中由于网络带宽原因,本地测试机上测试出的最大吞吐率会可能会远远小于服务器的最大吞吐率。所以本节我将讲述网络带宽是如何影响我们测试数据的,并给出示例和详细的解释。 正文什么是吞吐率? 吞吐率是指一个业务系统在单位时间内处理事务的总量。在事务的定义中可以是一个请求或者多个请求的集合,在Jmeter中可以用事务控制器(Transaction Controller)来控制。在资源有限的情况下每个系统都会有一个最大的吞吐率。在Jmeter中并发数和吞吐率有一定关系如下图。 200 * 1 * 100(200线程1s内启动循环100次,下同理) 200 * 1 * 1min(200线程1s内启动循环1分钟) 100 * 1 * 100(200线程1s内启动循环100次,下同理) 通过比较以上三种网络环境下的测试结果我们发现 三种不同网络环境下测试出最大的吞吐率不一致 不同环境执行同样脚本的出的测试结果不一致 三种不同网路环境下测试出的最大吞吐率也不是百度的最大吞吐率 某些网络环境下高并发比低并发的吞吐率低其实拿访问百度主页做测试也不太恰当,应为它的吞吐率用单机是不可能测试出来的。如果你们想验证一下上面的例子可以找一个类似于自己服务器上post请求的接口。不同网络环境下,因为带宽不同,所以我们本地测试机处理的请求也不同。比如现在本地带宽为2M,请求一次需要5kb,那每秒只能发送400个请求;但是如果本地现在带宽为4M,那每秒就能800个请求;但服务器的最大吞吐率为1000/s。 所以在性能测试中,我们一定要注意一项指标就是服务器CPU,来观测服务器资源使用和处理事务能力的关系。在本地网络环境测试中,由于网络不稳定所以可能会导致高并发比低并发的吞吐率低,为了规避这些不可控因素建议大家将测试环境放到云服务器上,这样网络会较为稳定,而且带宽也可以按需调整。 本节主要想表达的结论是:因为在请求过程中向服务器单位时间发送请求的数量并未达到最大吞吐率的值,所以我们不能把测出的值当做真实系统最大的吞吐率。除了带宽会对单位时间发送请求数量约束外,测试环境的CPU也会带来影响。因为每个线程默认为2M的空间,32位系统Java进程只能占2G,约1000个线程可用。64位系统无线程限制但会取决于CPU的大小。在测试过程中我们一定要查看测试机的资源使用情况,确定我们测试出的瓶颈源自服务器,而不是我们自己的测试机。希望可以解除你对测试数据中的一些疑惑,若有疑问请评论留言,谢谢。 PS:本系列第五节中关于本节也有论证!!! 你真的会使用Jmeter吗(五)性能测试中的有效数据 |
CopyRight 2018-2019 实验室设备网 版权所有 |