Posts

C++ 性能分析全景指南：从工具链到方法论 不要凭直觉猜瓶颈——人的直觉在性能问题上错误率极高。先量测，再优化。 写在前面 性能优化是 C++ 程序员的核心竞争力之一。但"性能优化"这四个字太大了——从微架构级的 cache line 对齐，到宏观的算法复杂度选择，中间跨越了多个抽象层次。 这篇文章不是某个工具的使用教程，而是试图建立一套完整的性能分析知识框架：遇到性能问题时，你该用什么工具、看什么指标、按什么思路排查。全文分为九个部分： 核心思维 CPU Profiling 内存分析 编译优化分析 Benchmark 编写 并发与锁分析 Sanitizer 全家桶 优化决策方法论 工具选择与学习路线 一、核心思维 1.1 性能问题的三种类型 所有性能问题，本质上只有三类： 类型 表现 典型原因 CPU-bound CPU 利用率高，但吞吐上不去 算法复杂度高、分支预测失败、指令级并行度低 Memory-bound CPU 利用率不高（在等数据），IPC 低 缓存未命中、TLB miss、false sharing、频繁堆分配 I/O-bound CPU 几乎空闲，程序却很慢 磁盘读写、网络等待、锁竞争（广义 I/O） 判断当前程序属于哪一类，是性能分析的第一步。用错了工具，你会在错误的方向上浪费大量时间。 1.2 Amdahl 定律的启示 优化一个占总耗时 5% 的函数，即使你把它优化到 0，整体也只快 5%。但优化一个占 60% 的函数，哪怕只快 20%，整体就快 12%。 永远先找大头。这就是为什么 profiling 必须走在优化前面。 1.3 量测的四条铁律 在接近生产环境的条件下量测——Debug 模式的热点分布和 Release 完全不同 量测时关闭无关进程——CPU 频率调节（turbo boost / power saving）会干扰结果 多次量测取统计值——单次运行的噪声太大，至少跑 3 次取中位数 量测前后只改一个变量——否则你不知道是哪个改动起了作用 二、CPU Profiling CPU 剖析是性能分析的基础。根据实现方式不同，分为采样式和插桩式两大类。 ...

Hical VS2022 快速上手 Demo 一个最小化的 Hical HTTP Server 示例，VS2022 编译即可运行，访问即返回含中文的 JSON 响应。 环境要求 项目 版本要求 Visual Studio 2022 17.6+ (需勾选"C++桌面开发"工作负载) vcpkg 最新版 CMake >= 3.20 (VS2022 自带即可) 第一步：安装依赖 (vcpkg) 1 2 3 4 5 6 7 # 如果还没装 vcpkg git clone https://github.com/microsoft/vcpkg.git C:\vcpkg cd C:\vcpkg .\bootstrap-vcpkg.bat # 安装 Hical 所需依赖（x64-windows 默认 triplet） .\vcpkg install boost-asio boost-system boost-json boost-beast openssl zlib --triplet=x64-windows 第二步：获取 Hical 源码 1 2 git clone https://github.com/user/hical.git cd hical 第三步：CMake 构建 1 2 3 4 5 # 配置（替换为你的 vcpkg 实际路径，-DHICAL_BUILD_TESTS=OFF 跳过测试编译，加快构建速度） cmake -B build -A x64 -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DHICAL_BUILD_TESTS=OFF # 编译 cmake --build build --config Release 编译成功后，可执行文件位于： ...

火焰图对比分析：自研 HTTP 栈 vs Beast HTTP 栈 Hical v2.6.0 完成了从 Beast HTTP 到自研零拷贝 HTTP 栈的迁移。本文通过两份火焰图的逐项对比，用数据量化"去 Beast"到底省了什么、省了多少，以及当前性能瓶颈到底在哪里。 目录 火焰图对比分析：自研 HTTP 栈 vs Beast HTTP 栈 目录 1. 测试环境与采集方式 2. 总体热度分布对比 flame.svg（自研路径）— 总计 ~299 亿 samples flame1.svg（Beast 路径）— 总计 ~411 亿 samples 3. HTTP 解析：picohttpparser vs Beast parser 4. Header 存储：栈数组 vs 链表堆分配 5. 响应序列化：FixedBuffer vs Beast serializer 自研路径 Beast 路径 6. 发送路径：sendto vs sendmsg 7. 协程与调度开销 8. 内核瓶颈：loopback softirq 的天花板 epoll_ctl 已不是瓶颈 9. strace 佐证：系统调用频率 10. 结论与下一步 量化收益：去 Beast 到底省了多少 当前性能分布总结 下一步优化方向 最终结论 1. 测试环境与采集方式 项目 配置 环境 Ubuntu VM (Docker 内)，GCC 14，-O2 -g 压测工具 wrk，4 线程，keep-alive 采集 perf record -F 99 -g -p <pid> → FlameGraph 生成 SVG 辅助 strace -c -f -p <pid> 统计系统调用频率 对比目标 flame.svg（自研路径 v2.6.0）vs flame1.svg（Beast 路径） 两份火焰图采集条件一致，唯一区别是 HTTP 处理栈的实现路径。 ...

起因 最初 Hical 的空闲超时实现就是传统做法：每个 HTTP 请求/每次 keep-alive 读等待都注册一个 steady_timer，读完成后取消，超时则关闭连接。实现上用的是 shared_ptr<function> 自引用环做回调链续期——每连接 2 次堆分配（shared_ptr 控制块 + function 对象），且每次续期都要重新构造回调。 v2.5.2 压测到 132K QPS 时，做热路径Review代码发现这个 timer 机制的问题： 每请求 2 次 epoll_ctl（注册 + 取消 timer） shared_ptr<function> 自引用环本身就有堆分配开销 140K QPS 下整体约产生 100 万次 epoll_ctl/sec，38% CPU 花在内核 _raw_spin_unlock_irqrestore（TCP spin_lock），而用户态框架代码只占不到 5% 瓶颈已经从用户态转移到内核态，减少进内核的次数成为核心策略。空闲超时的 timer 是明确可以砍掉的——30-60s 的超时精度要求本来就极低。 改良过程 分两步走： 第一步：先把 shared_ptr<function> 回调链改为独立协程 idleTimerLoop，消除自引用环和 2 次堆分配。这一步还是 per-connection 一个 timer 协程，只是实现更干净了。 第二步：发现即便使用协程，per-connection timer 仍然意味着每次 timer 到期时要走 scheduler 调度 + epoll_ctl。最终演化为"TcpServer 统一扫描"的设计——整个 server 只需要一个扫描协程，连接侧只写一个 atomic 值。 ...

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 原地重建全局池——先析构旧池，再构造新池： ...