序列化/压缩开销 Serialization / compression cost

原因 ID sp-serialize · 主责 研发团队·服务器开发

把要发送的数据转换成字节并压缩也要消耗 CPU，人多时这部分开销会暴增。

起因每次更新都要把结构体转换成字节并压缩 → 结果开销与人数的平方成正比增长 → 画面表现 发送变慢，表现为操作延迟

症状: 操作延迟
因素: 停顿, 延迟
谁会遇到: 特定地点/分线
何时出现: 人多的时候
负责方: 主责 研发团队·服务器开发
研发团队要做的事: 一个包做好后复用给多人；采用轻量格式。
监控图上: 随人数/负载上升 · 服务器 CPU 使用率、生成数据包的线程的 CPU
查看位置: 用 perf top -p 对比人少和人多时，游戏进程 CPU 时间中序列化、压缩、加密函数（包括 zlib、LZ4、OpenSSL 等库函数）的占比
确认依据: 人越多，序列化、压缩、加密函数的占比越大，生成数据包的线程的 CPU 先饱和
排除依据: 这些函数占比很小，看视野计算或游戏逻辑
确认手段: 运维工具即可确认（无需游戏代码）
深入了解: 如果连接对数据包加密（TLS、DTLS 等），加密和解密也要消耗 CPU。加密按连接分别处理，所以即使一个包复用给多人，加密开销仍按接收人数计算。AES-GCM 这类对称加密快到单核每秒能处理几 GB，平时占比很小；但速度会因一次加密的单位（记录，record）大小而差别很大，像游戏这样小包多的场景，每字节的开销会变大。每个连接一次的握手中，服务器要用证书私钥签名并计算密钥交换（ECDHE）。单核每秒签名约 1,100 次（RSA 2048）到 1.8 万次（ECDSA P-256），密钥交换约 9,000 次，登录集中时会成为负担。

出处

Introduction to Iris in Unreal Engine Epic Games
把要复制的状态保存为一份量化后的副本，减少昂贵操作，并让多个连接共用这份结果
VALORANT's 128-Tick Servers Riot Games
每帧为每个客户端比较复制变量、打包变化值的方式要四处读取内存，速度慢，大量占用服务器 CPU
How "expensive" is crypto anyway? Cloudflare
BoringSSL 测量：AES-128-GCM 每秒约 3.7 GB（随记录大小变化很大）；单核每秒 RSA 2048 签名 1,120 次、ECDSA P-256 签名 18,477 次、P-256 ECDHE 9,394 次；Cloudflare 边缘服务器上 TLS 库占用的 CPU 约 1.8%
perf-top(1) — Linux manual page perf
按函数（符号）实时显示运行中进程（-p）的 CPU 使用占比