WebBench 压测工具深度解析：在 C++ WebServer 项目中用 fork 模拟 3 万并发连接

后端Web框架网络【免费下载链接】WebServerA C High Performance Web Server项目地址https://gitcode.com/gh_mirrors/we/WebServer点击查看免费下载WebBench 是一个运行在 Linux 下的轻量级 HTTP 网站压测工具它通过fork()派生出多个子进程来模拟多个客户端同时访问指定 URL以评估目标网站在压力下的吞吐能力理论上最多可模拟 3 万个并发连接。本指南将围绕 WebBench/README.md 展开完整讲解其安装方式、命令行选项、输出指标含义并结合 WebBench/webbench.c 与 WebBench/socket.c 源码剖析其 fork 压测模型与请求构造原理帮助你直接用它对本仓库的 C WebServer 进行压测验证。为什么需要 WebBench压测场景与适用前提本仓库 README.md 明确说明项目使用 Epoll 边沿触发的 IO 多路复用、Reactor 模式与线程池构建了一个高性能 C Web Server而在服务器开发完成后需要借助压测工具验证其在并发压力下的真实表现。官方对开源 WebBench 进行了针对性改写——增加了 Keep-Alive 选项和测试功能这正是仓库内 WebBench/ 目录存在的意义。WebBench 的设计哲学是简单它只做一件事——用fork()模拟多个客户端持续向目标 URL 发送 HTTP 请求并统计结果。它并不追求像 ApacheBench、wrk 那样丰富的功能而是以极简的代码实现足够真实的并发负载。其 man 手册 WebBench/webbench.1 还特别指出与依赖select()的压测工具不同WebBench 使用多进程模拟多用户流量在 SMP 系统以及select()实现缓慢或有缺陷的系统上表现更好。需要说明的适用前提WebBench 是一个压测客户端运行时需要目标服务器处于可连接状态可以是本机 WebServer也可以是任意 HTTP 服务器或可通过 HTTP 代理访问的其他协议服务它运行在 Linux 平台构建依赖gcc、make与ctags。安装与构建从源码到命令行工具WebBench 的源码构成非常精简WebBench/webbench.c主程序包含参数解析、请求构造与压测核心逻辑约 567 行WebBench/socket.c网络连接封装源自 popclient 1.5 的公有领域 UNIX socket 代码由 Radim Kolar 修改WebBench/Makefile构建与安装脚本WebBench/webbench.1man 手册页。依赖项只有ctags用于生成源码标签文件见 Makefile 中tags: *.c规则。安装命令遵循 README 给出的方式sudo make sudo make install PREFIXyour_path_to_webbench其中PREFIX指定安装前缀默认值为/usr/local/webbench见 WebBench/Makefile。安装过程会执行如下操作对应 Makefile 的install目标将编译好的webbench二进制安装到$(PREFIX)/bin并软链接到/usr/local/bin/webbench使其可直接在命令行调用将 man 手册 WebBench/webbench.1 安装到$(PREFIX)/man/man1及系统 man 目录之后可用man webbench查看帮助将 WebBench/debian/copyright 与 changelog 安装为文档。编译细节可在 WebBench/Makefile 中调整默认CCgccCFLAGS-Wall -ggdb -W -O开启警告、调试信息与优化版本号为 1.5。仓库还附带 Debian 打包支持WebBench/debian/control、WebBench/debian/rules可用于生成 deb 包。仓库中已包含编译产物WebBench/webbench因此也可以直接执行该二进制或用make重新构建make clean可清理中间文件。命令行选项全解从 README 参数表到源码实现README 给出了完整的命令行选项表。下面将该表完整保留并逐项补充源码层面的行为细节对应 WebBench/webbench.c 中的long_options定义与 WebBench/webbench.c 的getopt_long解析逻辑短参长参数作用-f--force不需要等待服务器响应发送请求后立即关闭连接接近 DoS 攻击行为-r--reload发送重新加载请求附带Pragma: no-cache头-t--time sec运行多长时间单位秒默认 30 秒-p--proxy server:port使用代理服务器来发送请求-c--clients n创建多少个客户端默认 1 个-k--keep启用 HTTP/1.1 Keep-Alive 连接本仓库改写的核心新增选项-9--http09使用 HTTP/0.9-1--http10使用 HTTP/1.0 协议默认-2--http11使用 HTTP/1.1 协议--get使用 GET 请求方法默认--head使用 HEAD 请求方法--options使用 OPTIONS 请求方法--trace使用 TRACE 请求方法-?/-h--help打印帮助信息-V--version显示版本号1.5各选项的源码行为细节-f / --force不等待响应。对应全局变量force。源码中benchcore()在写完请求后跳过read()阶段直接计数WebBench/webbench.c。man 手册明确指出该选项能产生相当不错的 DoS 攻击效果所以压测线上服务时需谨慎使用。-r / --reload强制代理重新加载。对应force_reload。构造请求时仅在设置了代理proxyhost ! NULL的情况下附加Pragma: no-cache\r\n头WebBench/webbench.c不设代理时该选项无实际效果与 man 手册描述一致。-t / --time sec压测时长。对应benchtime默认 30 秒WebBench/webbench.c解析后若为 0 会被重置为 30WebBench/webbench.c。每个子进程通过alarm(benchtime)设置闹钟超时后由alarm_handler将timerexpired置 1压测循环随之退出WebBench/webbench.c。-p / --proxy server:port走代理。使用strrchr从右向左定位最后一个:来拆分server:portWebBench/webbench.c。三种边界情况处理无:则端口保持默认 80:在开头则报错Missing hostname:在结尾则报错Port number is missing。启用代理后请求行直接写入完整 URL如GET http://... HTTP/1.0并且不附加Host头。man 手册指出代理模式是访问HTTP 之外其他协议服务的唯一途径。-c / --clients n并发客户端数。对应clients默认 1解析后为 0 会被重置为 1WebBench/webbench.c。README 宣称最多可模拟 3 万个并发连接实际以 Linux 系统的fork()能力与进程数上限如ulimit -u为约束。-k / --keepKeep-Alive仓库改写新增。这是本仓库相对上游的重要增强对应全局布尔变量keep_aliveWebBench/webbench.c与 README.md 中对开源测试工具 Webbench 增加了 Keep-Alive 选项和测试功能的描述吻合。开启后请求头使用Connection: Keep-Alive否则使用Connection: closeWebBench/webbench.c且仅在 HTTP/1.1http101下该头才生效。-9 / -1 / -2协议版本。对应http10整型变量0 表示 HTTP/0.9、1 表示 HTTP/1.0默认、2 表示 HTTP/1.1WebBench/webbench.c。协议影响请求行与头的构造HTTP/0.9 只发送方法 路径无协议版本、无任何头、无结尾空行HTTP/1.0 追加HTTP/1.0版本号、User-Agent: WebBench 1.5与Host头HTTP/1.1 进一步追加Connection头WebBench/webbench.c。--get / --head / --options / --trace请求方法。对应method枚举GET0、HEAD1、OPTIONS2、TRACE3见 WebBench/webbench.c。构造请求时方法字符串被写入请求行起始位置。源码还会自动调整协议下限--head强制 HTTP/1.0 及以上--options与--trace强制 HTTP/1.1WebBench/webbench.c因为这些方法在更低的协议版本中不存在或不合理。-V / --version直接打印1.5并退出WebBench/webbench.c。README 表格未列出的-v短参在 man 手册中出现当前源码仅支持-V。典型压测命令仓库 WebBench/test.sh 给出了针对本 WebServer 的实测命令10 秒后手动结束60 秒、1000 并发、HTTP/1.1、GET./bin/webbench -t 60 -c 1000 -2 --get http://127.0.0.1:80/hello针对本仓库 WebServer 的其他常用场景# 压测非保活连接HTTP/1.1连接用完即关 webbench -c 100 -t 30 -2 http://127.0.0.1:8888/ # 压测 Keep-Alive 长连接场景仓库改写新增能力更贴近真实浏览器行为 webbench -c 100 -t 30 -2 -k http://127.0.0.1:8888/ # 只统计发送速率不等待响应 webbench -c 1000 -t 10 -f http://127.0.0.1:8888/ # 经代理压测 webbench -c 100 -t 30 -p 127.0.0.1:3128 http://example.com/注意WebBench 只直接支持http://前缀的 URL见 WebBench/webbench.c且 URL 长度不能超过 1500 字符、必须以/结尾否则报Invalid URL syntaxWebBench/webbench.c。URL 中允许显式携带端口如http://127.0.0.1:8888/未指定端口时默认 80WebBench/webbench.c。输出指标解读Speed、Requests 与失败计数压测结束后父进程汇总所有子进程结果并打印WebBench/webbench.cSpeed1800 pages/min, 12345 bytes/sec. Requests: 3000 susceed, 0 failed.三个核心指标的准确含义Speedpages/min页/分钟(speed failed) / (benchtime / 60.0f)即成功请求 失败请求的总请求数换算成每分钟速率统计的是请求发送总量而非响应完成量bytes/sec字节/秒bytes / benchtime所有子进程累计读取到的响应字节数除以压测时长反映响应吞吐Requests: susceed, failedspeed为成功完成写入请求且计数的次数failed为失败次数包括连接建立失败、写入失败、读取失败等WebBench/webbench.c 中所有failed分支。一个值得注意的实现细节定时器到期时若已累计失败计数源码会做一次失败校正failed--把闹钟中断本身导致的最后一次未完成请求从失败中剔除WebBench/webbench.c。因此压测时间到点时的failed数值可能略小于实际失败次数解读时应结合日志综合判断。压测原理剖析fork 多进程模型与内部工作流WebBench 的核心是bench()与benchcore()两个函数WebBench/webbench.c整体工作流如下连通性预检先Socket()连接一次目标失败则打印 Connect to server failed. Aborting benchmark. 并返回退出码 1WebBench/webbench.c。创建结果管道pipe(mypipe)建立父子进程间的数据传输通道WebBench/webbench.c。批量 fork 客户端循环clients次调用fork()。每个子进程sleep(1)后进入压测循环父进程继续 fork 出下一个子进程最终形成 1 个父进程 N 个压测子进程WebBench/webbench.c。这也是最多 3 万并发的实现基础——每个子进程就是一个独立模拟客户端。子进程压测每个子进程调用benchcore()先通过sigaction注册 SIGALRM 处理函数并alarm(benchtime)设定时长上限然后进入请求循环WebBench/webbench.c。结果回传与汇总子进程结束时将speed failed bytes三个数写入管道父进程用无缓冲setvbuf的fscanf逐个读取并累加WebBench/webbench.c。两种压测循环非 Keep-Alive 与 Keep-Alivebenchcore()内部根据keep_alive分支为两种模式WebBench/webbench.c非 Keep-Alive 模式默认每次请求都是连接-发送-读取-关闭s Socket(host, port); // 新建 TCP 连接 write(s, req, rlen); // 发送完整请求 read(s, buf, 1500); // 读取响应force0 时 close(s); // 关闭连接 speed; // 计数一次成功其中Socket()封装了域名解析gethostbyname或点分 IP 直转inet_addr、socket()与connect()WebBench/socket.c。HTTP/0.9 模式下还会在发送后调用shutdown(s, 1)关闭写方向WebBench/webbench.c。Keep-Alive 模式仓库新增先建立一个连接然后在该连接上循环写请求-读响应-计数连接保持不关闭一旦写入失败才重新连接WebBench/webbench.cs Socket(host, port); // 建立一次长连接 while (1) { if (timerexpired) ... // 到点退出 write(s, req, rlen); // 复用连接发送 read(s, buf, 1500); // 读取响应 speed; }这一模式正是本仓库 README.md 所述增加 Keep-Alive 选项和测试功能的具体落地用于验证 WebServer 对 HTTP 长连接的保持能力对应仓库主项目中连接的维护设计。注意读取逻辑非 Keep-Alive 模式下read()返回 0EOF即结束本次请求Keep-Alive 模式下依赖 HTTP 响应自身边界读取失败才计入失败。退出码约定main的返回码约定WebBench/webbench.c 与 man 手册一致退出码含义0压测成功完成1压测失败无法连接服务器2命令行参数错误如缺少 URL、URL 非法、proxy 格式错误3内部错误如 fork 失败、管道创建失败请求构造细节从 URL 到完整 HTTP 报文build_request()WebBench/webbench.c将用户输入的 URL 转换为实际发送的请求报文核心步骤合法性校验必须有://、必须以http://开头、长度 ≤ 1500、主机名后必须以/结尾主机与端口拆分非代理模式下从://之后解析主机名与端口:出现在/之前视为端口构造Host: host头请求行拼装方法 路径(或完整 URL) HTTP/x.y\r\n请求头拼装HTTP/1.0 起附加User-Agent: WebBench 1.5非代理模式附加Host代理 -r附加Pragma: no-cacheHTTP/1.1 附加Connection: close/Keep-Alive结尾空行HTTP/0.9 以上以\r\n结束报文。拼装完成后程序会先打印出待发送的完整请求报文\nRequest:\n%s\n压测前可据此确认请求头是否符合预期。结合本仓库 WebServer 的实战压测指引将 WebBench 与本仓库的 C WebServer 搭配使用时推荐如下流程启动服务器参考 Main.cpp 与 config.h 配置端口默认 80与线程池参数编译运行 WebServer准备压测 URL服务器需提供可访问的资源路径如仓库 old_version 中的 index.html 或自行编写的响应路径URL 必须以/结尾小规模冒烟先用webbench -c 10 -t 5 http://127.0.0.1:80/验证连通性与参数正确性观察输出的Request:报文是否符合预期逐步加压依次提升-c并发数与-t时长对比 Speed 与 bytes/sec 的变化观察服务器的 QPS 吞吐与稳定性对比保活与非保活分别用-2默认Connection: close与-2 -kKeep-Alive压测评估长连接复用对吞吐的影响这正对应本仓库对 WebBench 的 Keep-Alive 增强能力排查失败计数若failed持续增长优先检查连接数上限ulimit -n、进程数上限ulimit -u与服务器端日志仓库 base/ 提供了异步日志组件确认是客户端资源限制还是服务器处理瓶颈。压测时注意-c达到数万级别会派生大量进程务必确认系统允许的进程数上限-f模式接近 DoS 行为仅适合在受控环境验证极限吞吐。结语WebBench 以极简的 fork 多进程模型提供了最多 3 万并发连接的 HTTP 压测能力其全部逻辑集中在 WebBench/webbench.c 与 WebBench/socket.c 两个文件中易于阅读与二次改造。本仓库的这份副本在原生基础上增加了 Keep-Alive 选项配合 WebBench/test.sh 中的示例命令可直接用于对本仓库 C WebServer 进行长连接与短连接两种模式的对比压测。理解其参数、指标与退出码约定是正确解读压测结果、定位服务器性能瓶颈的第一步。赞分享后端Web框架网络【免费下载链接】WebServerA C High Performance Web Server项目地址https://gitcode.com/gh_mirrors/we/WebServer点击查看免费下载相关推荐exVim开发环境搭建终极指南如何用exVim开发exVim项目exVim开发环境搭建终极指南如何用exVim开发exVim项目 exVim是一款强大的Vim定制化开发环境它将Vim转变为优秀的编程IDE。本文将为您提供终极指南如何用WebBench轻松实现3万并发连接的网站负载测试终极指南如何用WebBench轻松实现3万并发连接的网站负载测试 WebBench是一款轻量级但功能强大的网站压测工具由Radim Kolar在1997年开运维WebServer 压测实战基于 Webbench 的短连接/长连接 QPS 对比测试与性能改进分析WebServer 压测实战基于 Webbench 的短连接/长连接 QPS 对比测试与性能改进分析 本文以开源仓库 we/WebServerC11 编后端Web框架网络上一篇FF14 ACT辍学插件完整指南三步快速跳过副本动画的终极方案下一篇PyQt-Fluent-Widgets深度解析现代化桌面应用开发的架构与实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考