Posts

写在前面 两万多行代码写下来，我把踩过的坑和想明白的事都总结在这了。不讲概念，只聊实战中每个设计"为什么这么做"。 搞 C++ Web 框架这事，从第一行代码到现在，说实话走了不少弯路。今天不聊怎么用，聊聊底层那些设计决策——为什么要这么写，当时碰到了什么问题，怎么一步步改成现在这样的。 一、编译期就把活干完 1. 一套模板搞定 TCP 和 SSL 最早我是分别写了 TcpConnection 和 SslConnection 两个类，代码重复率 80%以上，改一个 bug 要改两遍。后来换成 GenericConnection<SocketType>，内部用 if constexpr 做分支： 1 2 3 if constexpr (hIsSslStream<SocketType>) { co_await stream_.async_handshake(...); } 编译器直接在编译期把不匹配的分支丢掉——纯 TCP 的二进制里一个字节的 SSL 代码都没有。维护成本砍半，运行时零开销。这不是什么高深技巧，但真正落地用好的项目不多。 2. 用不到的模块，连编译都不参与 数据库、OpenAPI 这些模块，不是每个项目都用得上。我用 CMake option + 宏隔离的方式处理： 1 option(HICAL_WITH_DATABASE "Enable DB middleware" OFF) 代码里所有 DB 相关的逻辑都包在 #ifdef HICAL_HAS_DATABASE 里。你不开这个 option，这些代码连语法检查都不走，更别说占二进制体积了。比运行时搞个 feature flag 干净太多——运行时 flag 意味着代码虽然不执行，但死代码还在那占着 icache。 3. TRACE 日志：Release 下彻底消失 开发时满屏 TRACE 日志方便调试，但生产环境绝对不能有这些开销。我的做法是 NDEBUG 下 HICAL_LOG_TRACE 直接展开成 ((void)0)——注意，这不是"判断级别后跳过"，而是连参数求值的代码都不存在于二进制中。 ...

写在前面 你有没有想过，一个高并发网络服务器在同时给几千个客户端发消息时，底层到底在忙什么？ 最直觉的做法是加把锁——谁要发消息就抢锁、写 socket、放锁。但问题来了：如果 1000 个协程同时要给同一个连接发数据，它们就得排队等这把锁。锁竞争带来的上下文切换、cache 失效，会把性能拖进泥潭。 Hical 框架的解法很酷：用一个 MPSC（多生产者单消费者）无锁队列 做缓冲，配合一个协程写循环做消费。发消息的线程只管往队列里扔节点（wait-free，永远不阻塞），写循环协程在 IO 线程上批量取出、合并发送。 这篇文章会带你从零搞懂这个设计。不需要你有无锁编程的基础，但最好知道 C++ 的 atomic、shared_ptr 和"什么是协程"大概是怎么回事。 一、先搞清楚问题：为什么普通的锁不行？ 1.1 一个典型场景 假设你写了个聊天服务器。用户 A 发了条群消息，服务器要转发给群里 200 个在线用户。这意味着： 1 用户A的消息 → 广播逻辑 → 同时调用 200 个连接的 send() 如果 send() 内部用 mutex 保护写操作： 1 2 3 4 5 6 7 8 9 10 11 // 朴素实现（有严重性能问题） void Connection::send(std::string data) { std::lock_guard lock(writeMutex_); // 200个协程在这里排队 writeBuffer_.append(data); if (!writing_) { writing_ = true; doWrite(); // 触发实际的 socket 写入 } } 问题出在哪？ ...

协程框架高并发翻车了？三个C++ Web框架实测，结果出乎意料 上一版测完总觉得哪里不对，于是改了配置又跑了一遍——这次结果老实多了。 前言：为什么重新测了一遍 这篇文章其实是第二版了。上一篇发出来之后我越想越不对劲——当时每个容器只给了 512MB 内存，fd 上限也没显式调高，跑 10K 并发的时候实际上根本没撑到一万个连接。wrk 报了一堆 connect 8983 错误，真正建立的有效连接也就一千出头，所谓的"高并发 10K"测试本质上测的还是千级并发。那组数据里 Hical 高并发"遥遥领先"的结论，现在看有水分。 这次我把配置拉满了：每容器 1024MB 内存、nofile 上调到 65536，VM 内核参数也做了对应调优（somaxconn、tcp_max_syn_backlog、端口范围等），确保 wrk 发起的一万个连接能真正建立起来。同时精简了文章的对比范围——压测还是 6 个框架一起跑的（数据完整保留在文章末尾），但本文只聚焦 Hical、Drogon、Cinatra 三个第一梯队选手做深入分析。这三个在上一版常规场景里已经拉开了和其余框架的差距，继续带着 91 QPS 的 cpp-httplib 同框只会让图表失真。 结果确实和上次不一样，尤其是高并发部分的排名翻了个个儿。先把结论放在前面：常规负载下三个框架打得很近，但各自有各自的强项——Hical 在 JSON 和中间件场景领先，Cinatra 在纯吞吐和 JSON Echo 上更快，Drogon 在高并发场景下表现最好。 测试环境 宿主机硬件： 项目 配置 处理器 Intel Core i7-11700K @ 3.60GHz（8核16线程） 内存 32 GB 存储 SSD（900 GB） 宿主系统 Windows 10 Enterprise LTSC 2021 虚拟化环境： 项目 配置 虚拟化平台 Oracle VM VirtualBox 7.1（半虚拟化接口: KVM） Guest OS Ubuntu 24.04.3 LTS Server VM 分配 16 GB RAM / 8 CPU Docker Engine 29.4.3 + Compose v5.1.3 每框架容器 4 CPU + 1GB RAM，nofile=65536 压测工具 wrk 4.1.0（独立容器），4 线程 默认并发 100 连接 持续时间 30 秒 编译器 GCC 14.2（Ubuntu 24.04） 优化级别 Release（-O2） 采样方式 每场景连续跑 3 轮，取算术平均值 注：所有框架运行在同一台 VM 的 Docker 容器中，wrk 也在同一 Docker 网络内发起请求（容器间通信，无宿主机网络栈介入）。VirtualBox 虚拟化会引入一定开销，绝对 QPS 数值会低于裸机，但各框架的相对排名通常稳定。 ...

优化背景 Hical 是我写的 C++20/26 Web 框架，跑 Hello World 压测时起初只有 27K QPS，而同类框架（Cinatra 165K、Drogon 170K）差了将近一个数量级。目标很明确：追平 Cinatra/Drogon 的水平。 整个优化过程分 6 个阶段，不是拍脑袋乱改，每一步都是 perf + 火焰图定位瓶颈 → 想方案 → 写代码 → 跑压测验证 的循环。能看到数字变化才算数。 阶段 1：协程帧削减（v2.5.1-v2.5.2） 发现问题 perf 火焰图第一个大头：14.5% CPU 在 scheduler::wake_one_thread_and_unlock + pthread_cond_signal。 一开始以为是跨线程调度问题，仔细一看不是——是 Boost.Asio scheduler 每次 co_await resume 都要走的内部调度流程太重了。一个 Hello World 请求居然走了 4 个协程帧： 1 2 3 4 5 handleSession: co_await async_read → 帧 1（必需，I/O 等待） co_await router_.dispatch() → 帧 2（Router 本身是协程） co_await handler(req) → 帧 3（同步 handler 被包装成协程，不必要！） co_await async_write → 帧 4（必需，I/O 等待） 帧 1 和 4 是真正的 I/O 等待不可消除，但帧 2 和 3 完全是浪费——一个同步的 return HttpResponse("Hello") 被裹了两层协程。 ...

Hical 框架开发心得：七个深刻教训 引言 Hical 是一个基于 Boost.Asio 的现代 C++20/26 高性能 Web 框架，采用原生 HTTP/WebSocket 网络栈（picohttpparser + 自研 WebSocket），从第一行代码到现在的 45+ 测试文件、3 层内存池、协程化数据库中间件、自研日志系统、OpenAPI 自动生成、WsHub 广播管理器、QPS 从 27K 到 159K 的优化历程，一路走来踩了不少坑，也收获了很多。 这篇文章不讲 API 用法，也不讲架构教程——那些在其他文章里都有。这篇只聊开发过程中的真实体会：哪些决策事后证明是对的，哪些看似优雅的方案差点把自己埋了，以及最终选择背后的取舍逻辑。 目录 Hical 框架开发心得：七个深刻教训 引言 目录 一、C++20 协程是双刃剑 1.1 协程让异步代码变清晰了……吗？ 1.2 co_await 后 this 可能已经死了 1.3 io_context 析构时的协程帧：成员声明顺序陷阱 1.4 co_spawn(detached) 的悬空引用陷阱 1.5 异常传播：catch 里不能 co_await 1.6 收获：协程不是银弹 二、PMR 三层内存池——收益大但陷阱多 2.1 为什么要三层 2.2 踩坑：upstream 选错导致跨线程竞争 2.3 踩坑：allocator 忘了传播 2.4 收获：PMR 的收益在高并发场景才显现 三、模板 + Concepts 比虚函数继承更适合网络框架 3.1 GenericConnection 的零成本分流 3.2 NetworkBackend concept：可替换但不多态 3.3 收获：编译期分支 > 运行时分支 四、自研日志系统的价值 4.1 为什么不用 spdlog 4.2 六层架构的设计决策 4.3 两个关键的性能优化 4.4 收获：核心框架值得自研，应用项目直接用 spdlog 五、双轨反射——为未来留后路 5.1 问题：C++26 还没来，但 API 要现在设计 5.2 宏回退层的实现策略 5.3 收获：用宏模拟未来语言特性 六、移除 Boost.Beast——火焰图驱动的依赖清退 6.1 Beast 到底慢在哪 6.2 picohttpparser + 零拷贝请求 6.3 自研 WebSocket 栈的取舍 6.4 收获：数据驱动的依赖决策 七、WsHub 广播管理器——从"能用"到"好用"的 WebSocket 架构 7.1 问题：裸连接管理的困境 7.2 WsHub 的核心设计 7.3 写串行化：被忽视的并发陷阱 7.4 收获：框架应该管理连接生命周期 后记：ThreadSanitizer CI 揪出的隐藏竞态（v2.6） Boost.Asio 对象的跨线程操作 stop() 的并发调用：门卫模式 教训 总结：七条核心原则 一、C++20 协程是双刃剑 1.1 协程让异步代码变清晰了……吗？ 在引入协程之前，一个 HTTP 请求的处理链是嵌套回调： ...

Hical 生产部署实践：从编译优化到容器化 框架开发完了，测试也通过了——然后呢？“本地跑得好好的"和"线上稳定运行"之间，隔着编译优化、进程管理、反向代理、监控告警、容器编排一整套工程实践。这篇文章把 Hical 从开发环境搬到生产环境的完整链路走一遍，每个环节都给出可直接复用的配置模板。 目录 Hical 生产部署实践：从编译优化到容器化 目录 一、编译优化：榨干最后一点性能 1.1 Release 基础参数 1.2 LTO（链接时优化） 1.3 PGO（Profile-Guided Optimization） 1.4 静态链接 vs 动态链接 二、进程管理：别让服务裸奔 2.1 systemd 服务配置 2.2 信号处理与 Graceful Shutdown 2.3 多线程与多 acceptor（SO_REUSEPORT） 三、反向代理：Nginx 挡在前面 3.1 HTTP 反向代理 3.2 WebSocket 代理 3.3 SSL 终止策略 四、监控与可观测性 4.1 Prometheus 指标暴露 4.2 日志接入 ELK / Loki 4.3 健康检查端点 五、容器化部署 5.1 多阶段 Dockerfile 5.2 docker-compose 完整示例 5.3 Kubernetes 部署参考 六、性能调优检查清单 系统级 Hical 应用级 PMR 内存池 数据库连接池 日志系统 调优流程 一、编译优化：榨干最后一点性能 1.1 Release 基础参数 开发阶段用 Debug 方便调试，上线必须切 Release。区别不只是 -O2，还有 assert 消除、NDEBUG 定义（Hical 的 HICAL_LOG_TRACE 宏在 NDEBUG 下编译期完全消除）： ...

Heaptrack：找出 C++ 程序中的无效内存分配 你的火焰图上 malloc/free 占了 8% CPU。你知道分配太频繁了，但——是哪个函数在疯狂 new？每次 new 了多少字节？有没有更好的办法？ 故事：每秒 17000 次 malloc，但只有 41 次是浪费的 对我的 C++20/26 Web 框架（Hical）做 Heaptrack 分析时发现：136K QPS 下每秒 17457 次堆分配，但临时分配（分配后很快释放）只有 41 次/秒——说明 PMR 内存池策略生效了。 但第一版代码没有 PMR 时，临时分配高达 13 万次/秒。Heaptrack 精确告诉了我哪些 std::string 和 std::vector 是罪魁祸首，逐个消灭后内存分配开销从 8% 降到 < 0.1%。 这篇教你用 Heaptrack 做同样的事——精确定位哪个函数在做无效分配，然后干掉它。 一、Heaptrack 是什么 Heaptrack 是一个堆内存分配追踪器，记录程序运行期间的每一次 malloc/new/free/delete，告诉你： 总共分配了多少次？多少字节？ 哪个函数分配最多？（完整调用栈） 峰值内存使用在哪个时间点？ 有没有泄漏（分配了但从未释放）？ 临时分配有多少？（分配后很快释放——这是优化首要目标） 对比 Valgrind Massif Heaptrack Valgrind –tool=massif 性能开销 2~5x 减速 20~50x 减速 数据粒度 每次分配的完整调用栈 定期快照 GUI heaptrack_gui（丰富） ms_print（文本） 适用场景 日常分析（推荐） 极精确内存画像 一句话：Heaptrack 是 Valgrind Massif 的现代替代品，快 10 倍，信息更全。 ...

Linux 性能分析与优化实战指南 基于 Hical 项目的 Ubuntu 24.04 VM 环境（VirtualBox，8 CPU / 16GB RAM）。 前置条件：已完成 Hical-Linux开发环境 和 VM编译运行Hical-Benchmark流程 的环境搭建。 目录 零、工具安装 一、perf stat：硬件计数器分析 二、perf record + 火焰图：CPU 热点定位 三、Heaptrack：内存分配分析 四、缓存层次与 cache line 五、实战：Hical 性能分析全流程 六、速查卡 零、工具安装 0.1 一键安装所有性能工具 1 2 3 4 5 6 7 8 9 10 11 # perf（必须匹配内核版本） sudo apt install -y linux-tools-$(uname -r) linux-tools-generic # heaptrack（内存分配分析） sudo apt install -y heaptrack heaptrack-gui # FlameGraph（火焰图生成脚本） git clone --depth 1 https://github.com/brendangregg/FlameGraph.git ~/FlameGraph # 辅助工具 sudo apt install -y valgrind strace sysstat hwloc 0.2 内核参数调整（perf / heaptrack 权限） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # ── perf 权限 ── # 查看当前值（默认通常是 4，限制很严） cat /proc/sys/kernel/perf_event_paranoid # 临时放开（重启失效） sudo sysctl -w kernel.perf_event_paranoid=-1 sudo sysctl -w kernel.kptr_restrict=0 # ── ptrace 权限（heaptrack --pid 运行时附着需要） ── # 查看当前值（默认 1，禁止非父进程 ptrace） cat /proc/sys/kernel/yama/ptrace_scope # 临时放开（重启失效） sudo sysctl -w kernel.yama.ptrace_scope=0 # ── 永久生效（写入配置文件） ── cat << 'EOF' | sudo tee /etc/sysctl.d/99-perf.conf kernel.perf_event_paranoid = -1 kernel.kptr_restrict = 0 kernel.yama.ptrace_scope = 0 EOF sudo sysctl --system 各级别含义： ...

perf + 火焰图：5 分钟定位 C++ 程序的 CPU 瓶颈 你的服务器 CPU 跑满了，QPS 却上不去。top 告诉你"忙"，但不告诉你忙在哪。怎么办？ 故事：从 27K 到 136K QPS 我开发了一个 C++20/26 Web 框架（Hical），第一次压测只有 27K QPS，而同场景下 Drogon 和 Cinatra 都在 160K+。CPU 使用率 100%，top 没用，gdb 打断点太慢。 最终靠 perf record + 火焰图，5 分钟定位到瓶颈不在我的框架代码（仅占 2% CPU），而在 Boost.Asio 的调度层——跨线程 epoll_ctl 和 per-request timer 合计吃了 27% CPU。 优化后 QPS 从 27K → 136K。 这篇文章把我整套分析流程分享出来。不需要你用过 Hical，任何 C++ 服务器程序都适用。 一、工具安装（2 分钟搞定） 1 2 3 4 5 6 7 8 9 # perf（必须匹配内核版本） sudo apt install -y linux-tools-$(uname -r) linux-tools-generic # FlameGraph 脚本（Brendan Gregg 出品） git clone --depth 1 https://github.com/brendangregg/FlameGraph.git ~/FlameGraph # 放开 perf 权限（否则只能看到自己的进程） sudo sysctl -w kernel.perf_event_paranoid=-1 sudo sysctl -w kernel.kptr_restrict=0 验证： ...

缓存行对 C++ 性能的影响有多大？实测告诉你 面试题：“遍历 vector 比遍历 list 快多少倍？"——答案不是 2 倍，是 10~100 倍。原因只有一个字：缓存。 故事：为什么 vector 存 20 个 HTTP 头比 unordered_map 还快 开发 Hical Web 框架时，我面临一个选择：HTTP 请求头用什么容器存？ 直觉说 unordered_map<string, string> 查找 O(1)，肯定比 vector<pair<string, string>> 的 O(n) 快。但实测结果打脸——vector 线性扫描 20 个头部，比 unordered_map 哈希查找还快 40%。 原因就是 cache line。这篇文章讲清楚这件事。 一、CPU 缓存：被忽视的性能悬崖 1.1 速度鸿沟 你的程序跑在 CPU 上，但数据存在内存里。两者之间有一道巨大的速度鸿沟： 1 2 3 4 5 6 7 8 9 10 11 ┌──────────┐ │ CPU 寄存器│ ~0.3 ns (1 cycle) ├──────────┤ │ L1 Cache │ ~1 ns (3-4 cycles) 32-48 KB / 核 ├──────────┤ │ L2 Cache │ ~4 ns (10-12 cycles) 256 KB-1 MB / 核 ├──────────┤ │ L3 Cache │ ~12 ns (30-40 cycles) 8-32 MB / 共享 ├──────────┤ │ 主内存 │ ~60-100 ns (150-300 cycles) └──────────┘ 关键数字：L1 和主内存的延迟差 100 倍。 ...