TKeed 压测实战WebBench 1000 并发下的吞吐量、CPU 占用与 8 worker 调优对比【免费下载链接】TKeed High Performance HTTP WebServer项目地址: https://gitcode.com/gh_mirrors/tk/TKeedTKeed是一款基于 Reactor 模型的高性能 HTTP WebServer核心采用 epoll 非阻塞 I/O 线程池架构。本文使用经典压测工具 WebBench以1000 并发、60 秒为基准实测 TKeed 的吞吐量RPS、CPU 占用与系统负载完整对比 4 worker 与 8 worker 两种线程配置的调优结果帮你在 5 分钟内掌握 HTTP 服务器压测方法与线程数调优经验。一、压测环境WebBench 压测快速上手 本次压测环境如下本地环境保证结果可复现项目配置CPU4 核 i5 处理器操作系统Ubuntu压测工具WebBench 1.5源码见test_unit/webbench/webbench.c压测时长每轮 60 秒目标页面/index.html约 515 字节TKeed 默认监听 3000 端口worker 线程数由配置文件 tkeed.conf 中的thread_num控制服务构建与配置可在 makefile 与 main.c 中查看。通过以下命令即可启动 WebBench 压测./webbench -t 60 -c 1000 http://127.0.0.1:3000/index.html-t 60压测持续 60 秒-c 1000模拟 1000 个并发客户端连接WebBench 结束后会输出三项核心指标Speed每秒请求数与字节吞吐、succeed 成功数、failed 失败数它们是本文对比分析的全部依据。二、1000 并发压测结果4 worker 对比 8 worker 核心数据同样的压测条件1000 并发 × 60 秒仅调整 worker 线程数结果如下指标4 worker8 workerRPSpages/min671,102641,383带宽吞吐bytes/sec7,728,8587,303,634成功请求数671,102641,192失败请求数0191第一个结论可能有点反直觉worker 线程从 4 加到 8吞吐量不但没有提升RPS 反而下降约 4.4%还额外产生了 191 个失败请求。下面是 8 worker 压测期间的系统负载截图load average 仅约 1.034 核机器每个 tkeed 线程 CPU 占用稳定在 5% 左右为什么线程越多WebBench 压测结果反而越差这里有一条非常经典的调优经验worker 线程数 CPU 核心数。TKeed 的事件驱动循环本身是非阻塞的epoll 负责把 I/O 事件拆分成独立任务分发给线程池1000 并发下 4 个线程已能消化全部 I/O 事件再加 4 个线程不会带来真正的并行度提升多出来的线程只会引入线程上下文切换开销和线程池任务队列的互斥锁竞争反而拖慢整体响应。CPU 占用分析满负荷下总 CPU 仅约 40%这是本次压测最有说服力的一组数据在 671,102 RPS 的满负荷下TKeed 总 CPU 使用率仅约 40%4 线程时单线程约 10%8 线程时单线程约 5%。从上面的 top 截图可以印证用户态时间us只有 19.8%线程大部分时间处于等待 epoll 事件就绪的状态而不是忙轮询。这正是 Reactor 事件驱动模型相比传统一线程一连接模型的本质优势——线程数与并发数解耦CPU 占用可预测。三、1KB 标准页面测试响应体变大后吞吐量如何变化将响应体换成 1KB 标准页面同样 1000 并发 × 60 秒指标数值RPSpages/min641,201带宽吞吐bytes/sec12,831,604成功 / 失败641,083 / 118页面体积从约 515B 增大到 1KB 后RPS 略微下降671K → 641K但字节级吞吐量翻倍7.7 MB/s → 12.8 MB/s。这完全符合预期RPS 与页面大小成反比而带宽吞吐随页面体积同步放大。压测时用小页面测连接处理能力、用标准页面测带宽能力两者结合才是完整评估。四、压测成绩背后的架构Reactor 模型与线程池TKeed 能在 4 个线程下跑出 67 万 RPS靠的是这套架构完整设计说明见项目内 架构分析.md 与 并发模型.md事件循环epoll.c 负责 accept 连接、注册读事件与事件分发内核监听就绪后才通知全程不阻塞等待线程池threadpool.c 用互斥锁 条件变量避免忙等新任务入队后仅唤醒一个等待线程规避惊群效应请求处理http.c 的do_request读取请求、状态机解析http_parse.c、返回响应文件超时连接由 timer.c 的优先队列统一惰性清理。下面是整个服务器模块与函数的调用关系全景图可以清晰看到 main.c → epoll → threadpool → do_request 的完整调用链完整的压测原始数据与改进记录已归档在 测试及改进.md 中欢迎对照复现。五、调优结论3 条可直接复用的经验 线程数对齐核心数4 核机器上 4 worker 是最优解8 worker 反而劣化换机器时先设thread_num 核心数再实验性微调 看负载而不只看 RPS本次 8 worker 压测 load average 仅 1.03CPU 远未打满瓶颈在锁竞争与调度开销加线程没有意义 小页面 标准页面双测515B 页面反映连接处理能力1KB 标准页面反映带宽能力两者结合才能完整评估 WebBench 压测结果。一句话总结1000 并发下TKeed 以 4 worker 达成 671,102 RPS、0 失败总 CPU 占用仅约 40%盲目把 worker 加到 8 得不偿失——线程数 核心数是最稳的 HTTP 服务器压测调优公式。【免费下载链接】TKeed High Performance HTTP WebServer项目地址: https://gitcode.com/gh_mirrors/tk/TKeed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TKeed 压测实战：WebBench 1000 并发下的吞吐量、CPU 占用与 8 worker 调优对比
TKeed 压测实战WebBench 1000 并发下的吞吐量、CPU 占用与 8 worker 调优对比【免费下载链接】TKeed High Performance HTTP WebServer项目地址: https://gitcode.com/gh_mirrors/tk/TKeedTKeed是一款基于 Reactor 模型的高性能 HTTP WebServer核心采用 epoll 非阻塞 I/O 线程池架构。本文使用经典压测工具 WebBench以1000 并发、60 秒为基准实测 TKeed 的吞吐量RPS、CPU 占用与系统负载完整对比 4 worker 与 8 worker 两种线程配置的调优结果帮你在 5 分钟内掌握 HTTP 服务器压测方法与线程数调优经验。一、压测环境WebBench 压测快速上手 本次压测环境如下本地环境保证结果可复现项目配置CPU4 核 i5 处理器操作系统Ubuntu压测工具WebBench 1.5源码见test_unit/webbench/webbench.c压测时长每轮 60 秒目标页面/index.html约 515 字节TKeed 默认监听 3000 端口worker 线程数由配置文件 tkeed.conf 中的thread_num控制服务构建与配置可在 makefile 与 main.c 中查看。通过以下命令即可启动 WebBench 压测./webbench -t 60 -c 1000 http://127.0.0.1:3000/index.html-t 60压测持续 60 秒-c 1000模拟 1000 个并发客户端连接WebBench 结束后会输出三项核心指标Speed每秒请求数与字节吞吐、succeed 成功数、failed 失败数它们是本文对比分析的全部依据。二、1000 并发压测结果4 worker 对比 8 worker 核心数据同样的压测条件1000 并发 × 60 秒仅调整 worker 线程数结果如下指标4 worker8 workerRPSpages/min671,102641,383带宽吞吐bytes/sec7,728,8587,303,634成功请求数671,102641,192失败请求数0191第一个结论可能有点反直觉worker 线程从 4 加到 8吞吐量不但没有提升RPS 反而下降约 4.4%还额外产生了 191 个失败请求。下面是 8 worker 压测期间的系统负载截图load average 仅约 1.034 核机器每个 tkeed 线程 CPU 占用稳定在 5% 左右为什么线程越多WebBench 压测结果反而越差这里有一条非常经典的调优经验worker 线程数 CPU 核心数。TKeed 的事件驱动循环本身是非阻塞的epoll 负责把 I/O 事件拆分成独立任务分发给线程池1000 并发下 4 个线程已能消化全部 I/O 事件再加 4 个线程不会带来真正的并行度提升多出来的线程只会引入线程上下文切换开销和线程池任务队列的互斥锁竞争反而拖慢整体响应。CPU 占用分析满负荷下总 CPU 仅约 40%这是本次压测最有说服力的一组数据在 671,102 RPS 的满负荷下TKeed 总 CPU 使用率仅约 40%4 线程时单线程约 10%8 线程时单线程约 5%。从上面的 top 截图可以印证用户态时间us只有 19.8%线程大部分时间处于等待 epoll 事件就绪的状态而不是忙轮询。这正是 Reactor 事件驱动模型相比传统一线程一连接模型的本质优势——线程数与并发数解耦CPU 占用可预测。三、1KB 标准页面测试响应体变大后吞吐量如何变化将响应体换成 1KB 标准页面同样 1000 并发 × 60 秒指标数值RPSpages/min641,201带宽吞吐bytes/sec12,831,604成功 / 失败641,083 / 118页面体积从约 515B 增大到 1KB 后RPS 略微下降671K → 641K但字节级吞吐量翻倍7.7 MB/s → 12.8 MB/s。这完全符合预期RPS 与页面大小成反比而带宽吞吐随页面体积同步放大。压测时用小页面测连接处理能力、用标准页面测带宽能力两者结合才是完整评估。四、压测成绩背后的架构Reactor 模型与线程池TKeed 能在 4 个线程下跑出 67 万 RPS靠的是这套架构完整设计说明见项目内 架构分析.md 与 并发模型.md事件循环epoll.c 负责 accept 连接、注册读事件与事件分发内核监听就绪后才通知全程不阻塞等待线程池threadpool.c 用互斥锁 条件变量避免忙等新任务入队后仅唤醒一个等待线程规避惊群效应请求处理http.c 的do_request读取请求、状态机解析http_parse.c、返回响应文件超时连接由 timer.c 的优先队列统一惰性清理。下面是整个服务器模块与函数的调用关系全景图可以清晰看到 main.c → epoll → threadpool → do_request 的完整调用链完整的压测原始数据与改进记录已归档在 测试及改进.md 中欢迎对照复现。五、调优结论3 条可直接复用的经验 线程数对齐核心数4 核机器上 4 worker 是最优解8 worker 反而劣化换机器时先设thread_num 核心数再实验性微调 看负载而不只看 RPS本次 8 worker 压测 load average 仅 1.03CPU 远未打满瓶颈在锁竞争与调度开销加线程没有意义 小页面 标准页面双测515B 页面反映连接处理能力1KB 标准页面反映带宽能力两者结合才能完整评估 WebBench 压测结果。一句话总结1000 并发下TKeed 以 4 worker 达成 671,102 RPS、0 失败总 CPU 占用仅约 40%盲目把 worker 加到 8 得不偿失——线程数 核心数是最稳的 HTTP 服务器压测调优公式。【免费下载链接】TKeed High Performance HTTP WebServer项目地址: https://gitcode.com/gh_mirrors/tk/TKeed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考