简介
在对比了 jmeter 和 ab 以后使用了 ab 测试工具来测试服务器的性能,今天我们就来讲讲 ab 和 jmter 的并发模型,就是他如何保证能够模拟高并发客户端的场景的。
其实我们一说到并发,我们首先想到的就是服务端系统的并发模型,而为了能测试到这样的服务器系统的并发能力,性能测试工具也需要支持与之相应的并发包能力。而充分了解性能测试工具的并发模型,可以更好地帮助你选择适合自己的性能测试工具。其中 JMeter&&ab,Locust 和 Gatling 就选择了三种不同的发模型,这个应该是和开发者当时的技术背景,业务需求,资源情况等密切相关的。所以没必要去探究当时作者为什么要选择这个模型,但是可以尝试去理解这些不同模型的特点,从而选择到适合自己的模型。今天我们主要讲的 jmeter 和 ab 的模型,其他的我们后面有时间在做分析。
并发模型的相关概念
同步、异步、阻塞、非阻塞
要讲并发模型,我们绕不开以下四个名词:
同步(Synchronous)
异步(Asynchronous)
阻塞 (Blocking)
非阻塞(Nonblocking)
目前你能通过百度找到的、能查找到很多关于这些的解释,每个人都会有自己的一些理解。我这边不班门弄斧地来解释这四个词的差别,只是提一些大部分资料中忽视的点:
要区分同步、异步,必须讲清楚其所处的层,比如框架、用户空间、内核、IO 模型
同步调用发起后,没有得到结果不返回,那么毫无疑问就是被阻塞了
异步调用发起后直接返回,毫无疑问,这个进程没有被阻塞
在 Operating System Concepts [9th Edition](操作系统概念第 9 版本)该书中描述对进程间通信进行了一些描述
3828
也就是说,站在进程通信纬度上来看,阻塞、非阻塞与同步、异步是同义词,但是需要区分发送方、接收方:
上述不同类型的发送方法和不同类型的接收方法可以自由组合
另外,我们还知道 Linux 有五种 I/O 模型:
除了 Asynchronous I/O 以外,其余 4 种都是同步 IO
多进程/多线程
做开发的兄弟应该都能理解:
3829
了解上面的概念以后呢,然后我们再来讲讲 ab 和 jmeter 的并发模型
基于多线程并发的 ab、jmeter
ab、JMeter 分别是用 C、Java 开发的、基于多线程并发模型的压测工具,也是目前最流行的开源压测工具,两者的工作原理类似,如下图:
3830
不管 ab 还是 JMeter,其所谓的虚拟用户(vuser)就是对应一个线程
在单个线程中,每个请求(query)都是同步调用的,下一个请求要等待前一个请求完成才能进行
一个请求(query)分成三部分:
send - 施压端发送开始,直到承压端接收完成
wait - 承压端接收完成开始,直至业务处理结束
recv - 承压端返回数据,直至施压端接收完成
同一线程中连续的两个请求之间存在等待时间这种概念,即图中的空白处
总的来说,多线程模型的优劣势总结有如下 :
(1)重度依赖于开发语言和操作系统对多线程的支持
(2)多线程切换的时候资源消耗比较多,在同等资源的情况下,产生的有效并发数量小;
(3)多线程也相对容易产生错误,比如死锁,共享数据错乱;
(4)可以通过丰富的界面来减少二次开发导致上面的一些错误;
(5)通过扩展开发和插件实现分布式来满足并发量的不足;
(6)多线程的应用技术比较成熟,未来相当长时间,还会继续应用于很多性能测试工具。
(7)从应用角度来看,基于多线程的并发模型,往往需要设置最大并发数参数,而如果压测场景需要不断往上加压,那这类工具其实挺难应付的
参考
版权声明:本文由[烧鸡太子爷]发表于https://xie.infoq.cn/article/e18602d477e2208f9d0debb98
如有侵权,请联系commuinty@eolink.com删除。