性能优化

C++ Web 框架性能实测：Hical vs Drogon vs Crow vs Oat++ vs cpp-httplib vs Cinatra（2026） 上一篇横评我们从架构设计、功能完整度和开发体验角度对比了四个 C++ Web 框架。结论是"各有适合的场景"——但没回答一个关键问题：到底差多少。本文用硬数据补上这个缺口：相同硬件、相同容器、相同压测工具，12 个场景全量对比，包括别人不太敢贴的对自己不利的数据。 目录 1. 引言 2. 测试环境与方法论 3. 基础吞吐量对比 4. 中间件链开销对比 5. 高并发扩展性 6. 资源效率 7. 延迟分析 8. 综合分析与选型建议 9. 结论 10. 复现指南 1. 引言 C++ Web 框架的选型讨论中，最常听到三句话： “Drogon 在 TechEmpower 上排名很高” “Crow 极简，几行代码就能跑” “Oat++ 零依赖，开箱即用” “cpp-httplib 零依赖单头文件，几行就能搭 HTTP 服务” “Cinatra 是国产 C++20 协程框架，性能号称顶尖” 这些都是事实，但缺少在统一条件下的定量对比。框架官网的 benchmark 通常只跑 Hello World，且各自用不同的硬件、不同的压测工具、不同的并发参数——数据之间几乎没有可比性。 本文的定位： 补充 07 号文章 的定性对比，用数据量化各框架的性能差异 与 11 号文章 的跨语言对比形成互补——那篇回答"C++ 和 Go/Rust 差多少"，本篇回答"C++ 框架之间差多少" 所有数据可复现——Docker 一键启动，run_bench.sh 跑一遍就能拿到结果 2. 测试环境与方法论 2.1 硬件 & 容器环境 项目 规格 宿主机 Windows 10 Enterprise LTSC 2021，Intel Core i7-11700K @ 3.60GHz（8 核 16 线程），32GB 内存 虚拟机 Oracle VirtualBox 7.1，Ubuntu 24.04.3 LTS Server，8 CPU / 16GB 内存 / 102GB SSD Docker Docker Engine 29.4.3（VM 内原生运行，非 Docker Desktop） 容器资源 每容器限制 4 CPU + 512MB 内存 网络 Docker 内部 bridge 网桥，wrk 独立容器通过服务名访问各框架 网络拓扑说明：所有容器运行在 VirtualBox Linux VM 内的 Docker Engine 上，wrk 与六个框架容器处于同一 Docker bridge 网络，网络条件完全一致。 ...

Hical v2.6.0 性能优化心得：从 27K 到 159K QPS 的完整旅程 这篇文章记录了 Hical 从 v2.5.2 到 v2.6.0 的完整性能优化历程。不是罗列"我做了什么改动"，而是分享怎么发现问题、怎么思考方案、怎么验证效果——以及那些"看起来应该有用但实际没用"的弯路。希望对做 C++ 高性能服务器开发的同学有参考价值。 目录 Hical v2.6.0 性能优化心得：从 27K 到 159K QPS 的完整旅程 目录 1. 起点：27K QPS，差距 6 倍 2. 第一个教训：不要猜，要量 3. 找对方向：火焰图告诉你真相 4. 三阶段优化路线 5. 阶段一：调度模型重构（27K → 132K） 5.1 SO_REUSEPORT：消除跨线程调度 5.2 连接级 Timer + atomic 时间戳 5.3 结果 6. 阶段二：去 Beast，自研 HTTP/WS 栈（132K → 140K） 6.1 四个 Phase 6.2 零拷贝请求解析 6.3 结果 7. 阶段三：热路径微优化（140K → 159K） 7.1 修复 readBuf 残留数据丢弃（功能 BUG + 性能） 7.2 scatter-gather I/O 替代单 buffer 合并 7.3 其他微优化（含后续延迟分配优化） 7.4 结果 8. 最终火焰图：确认优化到位 9. 走过的弯路 弯路 1：优化不是瓶颈的代码 弯路 2：FixedBuffer 栈缓冲区太大 弯路 3：过早放弃 10. 总结：性能优化的方法论 原则一：Profiling 驱动，不靠直觉 原则二：按占比排序，从大到小 原则三：每步验证，不要积累 原则四：知道何时停手 最终成绩单 1. 起点：27K QPS，差距 6 倍 v2.5.1 的 Hical 在 Docker 环境（Ubuntu 24.04, GCC 14, 4 线程）下跑 Hello World benchmark，wrk 报出 ~27K QPS。 ...

Hical v2.5.2 性能优化实战：SO_REUSEPORT + 连接级 Timer 实现 3 倍 QPS 提升 在 火焰图分析中，我们定位到 Hical 的 QPS 瓶颈在 Boost.Asio 的 epoll 交互模型——跨线程调度（14.5%）和 timer 相关 epoll_ctl（12.5%）合计吃掉了 27% 的 CPU。[P1 优化]（Router 同步快速路径）无实质提升后，本文记录 P2/P3 两项优化的设计思路、实现细节和实测结果。 目录 1. 背景回顾 2. 优化方案 A：SO_REUSEPORT 多 Acceptor 3. 优化方案 B：连接级 Timer + Atomic 时间戳 4. 实测结果 5. 剩余差距与后续方向 6. 复现指南 1. 背景回顾 1.1 P1 优化无效的原因 v2.5.2 实现了 Router::dispatchSync() 同步快速路径，在无中间件场景下跳过协程帧分配。三轮 Docker 压测结果： 轮次 QPS 变化 v2.5.1（基线） 27,493 — v2.5.1（静态链接） 19,381 系统波动 v2.5.2（dispatchSync） 20,940 无实质提升 原因：Router::dispatch 在火焰图中仅占 0.24% CPU，同步快速路径省掉的协程帧（~40-130ns）被 Asio 调度层（27%）完全淹没。 ...

Hical 性能剖析实战：perf + 火焰图定位 QPS 瓶颈 在 C++ 框架性能实测中，Hical 的 Hello World QPS（~27K）远低于 Cinatra（165K）和 Drogon（161K）。静态链接 + strip 验证后确认瓶颈不在链接方式。本文记录用 perf record + 火焰图精确定位 CPU 热点的全过程。 目录 1. 背景与动机 2. Profiling 环境搭建 3. 数据采集 4. 火焰图分析 5. 优化方向 6. 复现指南 1. 背景与动机 1.1 已排除的因素 在本次 profiling 之前，已经通过对照实验排除了以下因素： 假设 验证方式 结论 动态链接 Boost 有性能损耗 改为 Boost 静态链接，重跑压测 QPS 无显著变化（27K → 27K） strip 影响性能 strip vs 不 strip 对比 无影响（符号表不参与运行时） 二进制体积（icache 压力） 7.8M(strip) vs 9.3M(不strip) QPS 在噪声范围内，非瓶颈 排除结论：性能瓶颈在框架运行时架构，需要 profiling 定位具体热点函数。 ...

2026 年 C++ Web 框架横评：Hical vs Drogon vs Cinatra vs Crow vs Oat++ 如果你在 2026 年启动一个需要 C++ Web 服务的项目，面前摆着 Drogon、Cinatra、Crow、Oat++ 和 Hical 五个选择。该怎么选？本文从架构设计、异步模型、内存管理、功能完整度、开发体验五个维度做一次横向对比，帮你快速定位最适合的框架。 一句话概括 框架 一句话定位 Drogon 久经考验的高性能全栈框架，TechEmpower 榜单常客 Cinatra header-only 的 C++20 协程 HTTP 框架，阿里 yalantinglibs 生态成员 Crow 极简轻量的微框架，Express.js 风格，上手最快 Oat++ 零依赖、内置 Swagger 的 API 框架，嵌入式友好 Hical 自研 HTTP/WS 栈 + PMR 内存池 + C++26 反射的现代全栈框架 核心对比表 Hical Drogon Cinatra Crow Oat++ C++ 标准 C++20（C++26 就绪） C++17 / C++20 C++20 C++14 / C++17 C++11+ 异步模型 协程（co_await 全链路） 回调 + 协程混合 协程（async_simple::Lazy） 回调 自研异步 API 内存管理 PMR 三层内存池 默认分配器 默认分配器 默认分配器 默认分配器 HTTP 解析 picohttpparser（自研栈） 自研（Trantor） 自研 自研 自研 SSL/TLS 编译期模板分支 运行时分支 运行时配置 运行时分支 运行时分支 路由 哈希表 O(1) + 参数线性 基数树 字符串匹配 + 正则 前缀树 Controller 映射 中间件 洋葱模型（协程链） Filter 链 AOP 切面 基础 Interceptor WebSocket 内置（自研 RFC 6455） 内置 内置 内置 内置 Cookie / Session 内置（RFC 6265） 内置 有限 有限 有限 文件上传 内置（DoS 防护） 内置 内置 需手动 内置 静态文件 内置（ETag/304） 内置 内置 需手动 有限 ORM 协程化 DB 中间件（MySQL） 内置（PG/MySQL/SQLite） 无（生态有 ormpp） 无 模块化（PG/SQLite/Mongo） OpenAPI/Swagger 内置（自动生成 + Swagger UI） 第三方 无 无 内置 日志系统 内置（6 级 + 异步双缓冲 + 通道路由） 自带（简易） 基础 无 自带（loggers） CORS 内置中间件 内置 需手动 需手动 内置 HTTP/2 不支持 支持 不支持 不支持 不支持 反射/自动序列化 C++26 双轨（原生 + 宏） 无 生态有 struct_json/struct_pack 无 宏 DTO 系统 HTTP 客户端 无 内置 内置（协程化） 无 内置 外部依赖 Boost.Asio + OpenSSL + zlib Trantor + jsoncpp + … 无（可选 OpenSSL） Asio 零依赖 License MIT MIT MIT BSD-3 Apache-2.0 深度对比 1. 异步模型 这是选框架时最该关注的维度，因为它决定了你写业务逻辑的方式。 ...

VM 直接编译运行 Hical Benchmark 流程 不走 Docker，直接在 VM 上编译项目源码 + bench_server，用 wrk 压测。 适用于需要验证本地代码改动的场景（如性能优化后的 A/B 对比）。 前置条件 VM 里已有 Hical 项目源码：~/projects/Hical/ 已安装编译依赖（GCC 14+、CMake 3.20+、Boost 1.82+、OpenSSL） 挂接点 /mnt/hical_host/ 对应宿主机 d:/hical/Hical/ 一、同步宿主机代码改动到 VM 如果在宿主机上修改了源码，需要先拷贝到 VM 项目目录： 1 2 3 4 5 # 示例：拷贝 3 个改动文件 cp /mnt/hical_host/src/core/HttpServer.h \ /mnt/hical_host/src/core/HttpServer.cpp \ /mnt/hical_host/src/core/HttpSessionImpl.cpp \ ~/projects/Hical/src/core/ 或者整体同步 src 目录： 1 rsync -av /mnt/hical_host/src/ ~/projects/Hical/src/ 二、编译 1 2 3 4 5 6 7 8 9 10 cd ~/projects/Hical # 清理旧构建（可选，首次或 CMake 配置变更时执行） rm -rf build # 配置：Release + 编译 bench_server cmake -B build -DCMAKE_BUILD_TYPE=Release -DHICAL_BUILD_BENCH=ON # 编译（-j 自动取 CPU 核数） cmake --build build -j$(nproc) 编译产物：build/bench_server（直接链接本地 hical_core 库，代码改动即生效）。 ...

实测：C++ vs Go vs Rust，谁的 Web 性能更强？ “2026 年了，还有人用 C++ 写 Web 服务？” 这个问题我被问过不止一次。答案是：有，而且有相当充分的理由。本文不是要说服你用 C++，而是把三种语言放在同一个擂台上，用数据说话，帮你在实际项目里做出最合适的选择。 目录 1. 背景：三种语言在 Web 领域的 2026 年现状 2. 测试环境与方法论 3. Hello World QPS 对比 4. JSON CRUD QPS 对比 5. 内存占用对比 6. 开发效率对比 7. 生态与工具链对比 8. 各语言适用场景 9. 总结 1. 背景：三种语言在 Web 领域的 2026 年现状 C++：从游戏服务器到高性能 API C++ 在 Web 领域长期处于"少数派"地位，但 2020 年代之后情况在变化。C++20 协程（co_await）和 PMR 内存池让 C++ 的异步 Web 编程体验大幅改善；C++26 的反射提案进一步压缩了模板样板代码。游戏公司、金融公司、CDN 基础设施商是 C++ Web 服务的主要用户群——他们要么已经有大量 C++ 代码，要么对延迟的要求超出了 GC 语言的舒适区。 ...