• Web压测工具http_load原理分析


    01、前言

    http_load是一款测试web服务器性能的开源工具,从下面的网址可以下载到最新版本的http_load:

    http://www.acme.com/software/http_load/

    这个软件一直在保持着更新(不像webbench,已经是十年的老古董了。

    webbench的源码分析请参考:http://www.cnblogs.com/xuning/p/3888699.html ),并且更新频率还蛮高的样子。好在每个版本之间差别非常小,本文还是具有较好的通用性的。

    02、使用方法

    下载并解压缩之后,进入工具的根目录直接make,就可以得到可执行的工具。

    其使用方法如下图所示:
    在这里插入图片描述
    图中所示的url.txt内容是若干url链接,每行一个,详细说明一下使用格式:

    ./http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [timeout secs] [-sip sip_file]
    
             -parallel N | -rate N [-jitter]
    
             -fetches N | -seconds N
    
     url_file
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    选项与参数:

    -fetches:

    总计要访问url的次数,无论成功失败都记为一次,到达数量后程序退出。

    -rate:

    每秒访问的次数(即访问频率),控制性能测试的速度。

    -seconds:

    工具运行的时间,到达seconds设置的时间后程序退出。

    -parallel:

    最大并发访问的数目,控制性能测试的速度。

    -verbose:

    使用该选项后,每60秒会在屏幕上打印一次当前测试的进度信息。

    -jitter

    该选项必须与-rate同时使用,表示实际的访问频率会在rate设置的值上下随机波动10%的幅度。

    -checksum

    由于要访问某个url很多次,为了保证每次访问时收到的服务器回包内容都一样,可以采用checksum检查,不一致会在屏幕上输出错误信息。

    -cipher:

    使用SSL层的时候会用到此参数(url是https开头),使用特定的密码集。

    -timeout:

    设置超时时间,以秒为单位,默认为60秒。每超过一次则记为一次超时的连接

    -proxy:

    设置web代理,格式为-proxy host:port

    -throttle:

    限流模式,限制每秒收到的数据量,单位bytes/sec。该模式下默认限制为3360bytes/sec。

    -sip:

    指定一个source ip文件,该文件每一行都是ip+port的形式。

    需要特别说明的是:

    -parallel参数 和 -rate参数 中必须有一个,用于指定发请求包的方式;

    -fetches 和 -seconds两个参数必须有一个,用于指定程序的终止条件。

    03、与webbench的对比

    webbench是另外一款网页性能测试工具,它采用多进程发包,最多支持3万并发量,而http_load采用单一进程并行复用方式发包。

    由于只有一个进程,http_load对于机器资源消耗较小,性能要求不高,但它的劣势就是最大并发量比webbench要少许多,只能达到千的量级。在很多场景中,几千的量级也已经绰绰有余了,因此具体工具的选用还要看实际情况。

    我们分别使用webbench和http_load对同一个URL进行压力访问,结果如下。

    [horstxu@vps ~/webbench-1.5]$ ./webbench -t 30 -c 1000 http://127.0.0.1:8080/user.png
    
    
    
    Webbench - Simple Web Benchmark 1.5
    
    
    
    Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
    
    
    
    Benchmarking:GET http://127.0.0.1:8080/user.png
    
    
    
    1000 clients, running 30 sec.
    
    
    
    Speed=180340 pages/min, 5268934 bytes/sec.Requests: 90170 susceed, 0 failed.
    
    
    
    [horstxu@vps ~/http_load-02aug2014]$ ./http_load -parallel 1000 -fetches 90000 url.txt    
    
    
    
    90000 fetches, 830 max parallel, 1.2933e+08 bytes, in 30.5439 seconds
    
    
    
    1437 mean bytes/connection
    
    
    
    2946.58 fetches/sec, 4.23424e+06 bytes/sec
    
    
    
    msecs/connect:0.772754 mean, 215 max, 0.025 min
    
    
    
    msecs/first-response: 17.2259 mean, 288.007 max, 1.735 min
    
    
    
    HTTP response codes:  
    
    
    
         code 20090000
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53

    如果进行一下换算,webbench测得的页面RPS为180340 pages/min = 3006rps,这与http_load的测试结果2946fetches/sec结果是很接近的,并且,http_load统计数据更加全面,数据校验也更加完善。对于每秒流量数据,webbench的结果是5268934bytes/sec,http_load是4234240bytes/sec。

    这其中的差别在于,http_load在统计时剔除了http报文的头部(head),而webbench是没有剔除头部的。接下来我们来领略一下http_load的实现原理。

    04、工作流程

    程序的工作流程可以用下面这幅图来表示,执行时程序主要环节位于流程图中的循环内。

    http_load为单一进程的程序,因此进程内的所有调用都是非阻塞方式进行, 保证程序的流畅度。

    程序的执行过程主体在一个大循环当中,不间断进行结束条件的判定和超时判定。

    时间管理方式是使用拉链式哈希表,超时情况下即运行超时处理函数。
    在这里插入图片描述
    05、原理分析

    1、程序执行过程解析

    如果使用简化的代码来描述上一节所述的流程图,可以参考下图。流程图中的循环也就是主函数中的for循环。

    在主循环内主要做4件事情:

    首先,检测当前程序是否满足终止条件,如果满足,则调用结束函数退出程序,否则进行下一步。

    然后,采用select监听描述符状态,一旦出现可读或可写状态的描述符,则采用handle_connect与handle_read两函数分别进行处理。

    需要提醒的是

    源程序在处理读取socket缓冲区这一段为了完美剔除掉http请求报文的头部,耗费了大量的代码。

    再然后,循环尾部执行超时检测,检查当前时间有没有超过在哈希表中注册的每一个时间戳,如果超过,则要执行其对应的超时处理函数。

    源码中共有5种时间戳需要注册,分别对应着5个超时处理函数,请参考图中的超时处理函数集合。
    在这里插入图片描述
    2、三个重要的结构体

    下图中详细描述了三个源码中最为重要的结构体。

    首先,程序采用全局变量connections数组控制每一个TCP连接,connections数组中每个元素都是一个指向connection结构体的指针。connection结构体包含了用于记录测试数据的变量,连接状态的控制变量,以及最开始从文件中读取的连接配置信息。

    第二个结构体为url结构体,在http_load当中,想要请求的url存储在文件内,可以大于一个。

    这些URL的信息会被读取至由指向url结构体的指针组成的urls数组。请求会随机发向这些数组。相比webbench,http_load的一个优势是它的数据校验环节。每一个url会配有返回请求的checksum值,用于校验每次请求同一个url返回的内容是否一致。

    第三个结构体是时间管理方法中组成拉链式哈希表的每一个节点。它包含了指向超时处理函数的指针,以及记录超时时间的变量。
    在这里插入图片描述
    3、时间戳管理方法

    http_load中最为巧妙的就是它的时间管理方法。在该工具中,有很多需要定时触发的地方,比如每隔一段时间输出一份测试进度汇报;链接超过一定时间未响应则记为超时,输出超时错误信息;设定发送频率,每隔一段时间发出一个请求等等。这些时间戳和其超时触发的函数以Timer结构体的形式,全部注册于拉链法构成的哈希表中。每个链表都是以时间戳顺序从早到晚依次排列。

    这样,在每一个for循环执行超时检测的部分,我们可以很方便地判断出当前时间是否已经超过了时间
    戳的时间,如果超过,则执行超时处理函数。同时,这样的数据结构也提高了插入新时间戳的效率。
    在这里插入图片描述
    06、结语

    http_load与webbench都是很常用的压测工具,如果配合使用,结果做对比,既是对测得结果的校验,也能帮助熟悉两种工具的优劣。http_load的设计思路也可以使用到业务测试工具中来,帮助开发出更高效的压测工具。

    学习安排上

    如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

    在这里插入图片描述

    视频文档获取方式:

    这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片进群即可自行领取

  • 相关阅读:
    AOP的代理方式
    数据结构——3道栈和队列OJ题
    分布式ID生成算法|雪花算法 Snowflake | Go实现
    数字化改革“1612”详解
    安卓常见设计模式10------责任链模式(Kotlin版)
    Swift中和C语言数据类型转换
    (02)Cartographer源码无死角解析-(28) GlobalTrajectoryBuilder构建过程与整体分析
    数据库误修改后的数据恢复
    vue3+ts项目04-国际化
    分布式理论基础:CAP定理
  • 原文地址:https://blog.csdn.net/xfw17397388089/article/details/128161357