Hical

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.6.0：移除 Boost.Beast，自研 HTTP/WebSocket 栈全记录 Hical v2.6.0 完成了一次关键架构升级——彻底移除 Boost.Beast 依赖，HTTP 解析/序列化和 WebSocket 全部替换为自研实现。本文从动机、架构设计、关键技术细节、性能数据四个维度，完整记录这次"去 Beast"的工程实践。 目录 Hical v2.6.0：移除 Boost.Beast，自研 HTTP/WebSocket 栈全记录 目录 1. 为什么移除 Boost.Beast 2. 新架构总览 3. 自研 HTTP 解析栈 3.1 picohttpparser：极致轻量的 C 解析器 3.2 零拷贝 NativeRequest 3.3 HeaderMap：L1 友好的头部容器 4. 自研 HTTP 响应序列化 4.1 栈缓冲 + Scatter-Gather I/O 4.2 状态行预计算 5. 自研 WebSocket 栈（RFC 6455） 5.1 帧解析器：WsFrame 5.2 握手协议：WsHandshake 5.3 Permessage-Deflate 压缩 5.4 消息分片重组 5.5 协议安全校验 6. 编译防火墙与工程化 7. 性能对比数据 火焰图逐项对比 QPS 端到端对比 与同类框架对比 8. 迁移影响与 Breaking Changes 对框架使用者 对框架使用者透明的改动 9. 新增依赖 picohttpparser zlib 10. 总结 1. 为什么移除 Boost.Beast Beast 是一个优秀的 HTTP/WebSocket 库，但在 Hical 的高性能场景中，它成了主要瓶颈： ...

Hical 踩坑实录五部曲（五）：Boost.MySQL 协程集成的 5 个坑 引言 Hical 的数据库模块（src/db/）是一个基于协程的连接池 + 中间件系统，后端使用 Boost.MySQL 的 any_connection。从 “能跑” 到 “能在生产环境跑”，中间踩了不少坑。 这篇文章记录了 Boost.MySQL 协程集成过程中遇到的 5 个真实问题，每个都附带完整的解决方案代码。 目录 Hical 踩坑实录五部曲（五）：Boost.MySQL 协程集成的 5 个坑 引言 目录 坑 1：any_connection vs 强类型连接的取舍 坑 2：PreparedStatement 失效与自动重试 坑 3：SET NAMES 注入风险——validateCharset 白名单 坑 4：连接池 acquire 超时的竞争窗口 坑 5：事务忘记 commit/rollback 的自动回滚设计 第一道防线：DbMiddleware 洋葱模型 第二道防线：连接池 release 兜底回滚 附：StmtCache LRU 缓存设计 总结：Boost.MySQL 集成检查清单 坑 1：any_connection vs 强类型连接的取舍 现象：第一版连接池用 Boost.MySQL 的强类型连接（tcp_ssl_connection），结果泛型代码全部被迫模板化——编译时间爆炸，且无法在运行时根据配置切换 TCP/SSL。 强类型方式的问题： 1 2 3 4 5 6 7 8 9 10 11 // ❌ 强类型——泛型代码必须模板化 template <typename Connection> class DbPool { std::vector<std::unique_ptr<Connection>> idle_; // Connection 是 tcp_connection 还是 tcp_ssl_connection？ // 中间件也要模板化、查询日志也要模板化... }; // 编译时决定，运行时无法切换 using Pool = DbPool<boost::mysql::tcp_ssl_connection>; 解决方案：any_connection——类型擦除，运行时决定传输层： ...

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 踩坑实录五部曲（四）：PMR 三层内存池——从理论完美到实战翻车 引言 Hical 的内存管理采用 C++20 PMR（Polymorphic Memory Resource）三层池架构：全局同步池 → 线程本地无锁池 → 请求级单调缓冲。理论上完美——每一层解决一个特定的性能瓶颈。 但理论和实战之间，隔着一堆坑。 这篇记录了三层 PMR 池在开发和压测过程中遇到的 7 个真实问题——从跨线程 UAF 到 GC 永远不触发、从 CAS 自旋到缓冲区膨胀，每个都是排查半天以上的教训。 目录 Hical 踩坑实录五部曲（四）：PMR 三层内存池——从理论完美到实战翻车 引言 目录 坑 1：configure() 原地重建的 use-after-free 坑 2：generation 缓存失效的竞争窗口 坑 3：GC 标记了但永远不回收——死线程的内存泄漏 坑 4：CAS 峰值更新的缓存行风暴 坑 5：请求级单调池的 upstream 选错 坑 6：PmrBuffer 缩容不及时导致内存膨胀 坑 7：allocator 传播链断裂——PMR 白忙一场 总结：PMR 三层池的使用清单 坑 1：configure() 原地重建的 use-after-free 现象：在服务启动流程中调用 MemoryPool::configure() 后，偶发崩溃，堆栈指向 synchronized_pool_resource 的内部结构。 根因：configure() 使用 placement new 原地重建全局池——先析构旧池，再构造新池： ...

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 定位具体热点函数。 ...

Hical 踩坑实录五部曲（三）：自研日志系统的 8 个血泪教训 引言 Hical 没有用 spdlog、glog 或任何第三方日志库——整套日志系统完全自研，覆盖 20+ 个源文件：格式化、Sink 后端、文件轮转、异步双缓冲、通道分流、HTTP 集成、运行时调级。 自研日志的好处在开发心得里聊过了。这篇只聊坑——从"能跑"到"能在生产环境跑"的过程中，踩过的 8 个真实问题。 目录 Hical 踩坑实录五部曲（三）：自研日志系统的 8 个血泪教训 引言 目录 坑 1：异步写盘的背压——日志不应该成为延迟来源 坑 2：双缓冲析构时丢日志 坑 3：多线程 Sink 分发的锁竞争——COW 模式的引入 坑 4：日志注入——一条恶意日志伪造十行告警 坑 5：LogAdmin 的审计致盲攻击 坑 6：TRACE 日志在 Release 构建中的隐性开销 坑 7：trace-id 生成的性能瓶颈——OpenSSL 全局锁 坑 8：文件轮转的误删风险 总结：自研日志系统的检查清单 坑 1：异步写盘的背压——日志不应该成为延迟来源 现象：压测时发现 P99 延迟间歇性飙高。排查发现不是业务逻辑慢，而是日志写入阻塞了请求线程。 根因：早期版本的日志直接在调用线程同步 fwrite。高并发下磁盘 I/O 成为瓶颈，日志调用从微秒级退化为毫秒级。 引入异步 AsyncFileSink 后，新的问题出现——如果日志产生速度远超写盘速度（比如某个 bug 触发了大量 ERROR 日志），前端缓冲区会无限增长直到 OOM。 解决方案：背压保护——缓冲区超限时主动丢弃，而非阻塞或 OOM： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 // AsyncFileSink.cpp — write() 中的背压丢弃 void AsyncFileSink::write(std::string_view formattedLine) { std::lock_guard<std::mutex> lock(m_bufMutex); // 背压保护：缓冲区过大时丢弃（防止内存爆炸） if (m_curBuf.size() > m_opts.backpressureLimit) { m_dropped.fetch_add(1, std::memory_order_relaxed); return; // 丢弃这条日志，但不阻塞调用线程 } m_curBuf.append(formattedLine.data(), formattedLine.size()); // 缓冲区接近满时通知后台线程 if (m_curBuf.size() >= m_opts.bufferSize) { m_cond.notify_one(); } } 关键细节：丢弃计数不是默默吞掉的——后台线程在每次刷盘时检查丢弃计数，并将统计写入日志文件： ...

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. 异步模型 这是选框架时最该关注的维度，因为它决定了你写业务逻辑的方式。 ...

Hical Linux 开发环境（实操记录） 概述 将 Hical C++20 Web 框架的日常开发环境从 Windows 本地迁移到 Linux 虚拟机，通过 Oracle VM VirtualBox 运行 Ubuntu 24.04.3 LTS Server 虚拟机，使用 Tabby Terminal + VS Code Remote SSH 进行开发。 为什么迁移 痛点 Linux 解决 MSYS2/vcpkg 路径混乱、ABI 不兼容 原生 apt 包管理，toolchain 统一 liburing/io_uring 仅 Linux 可用 原生支持，解锁异步文件 I/O 最优路径 CI 环境是 Ubuntu，本地是 Windows 开发即 CI，减少"本地能跑 CI 挂"的问题 clang-format/clang-tidy 版本对齐困难 直接装 LLVM APT 源的 clang-20 Sanitizer（ASan/UBSan）Windows 支持差 Linux 原生完美支持 宿主机配置 项目 值 处理器 Intel Core i7-11700K @ 3.60GHz（8核16线程） 内存 32 GB 操作系统 Windows 10 Enterprise LTSC 2021 VM 存放磁盘 D:\ （900 GB，SSD） 一、VirtualBox 虚拟机创建 1.1 下载 软件 版本 下载地址 VirtualBox 7.1+ https://www.virtualbox.org/wiki/Downloads Ubuntu ISO ubuntu-24.04.3-live-server-amd64.iso（3.1 GiB） https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/24.04/ 选择 Server 版（无桌面 GUI），减少资源占用。国内推荐清华镜像下载更快。 ...