webman广播变慢因默认foreach遍历连接逐个send，导致重复序列化和系统调用；应预序列化消息、用redis pub/sub分发、按uid分片连接，并仅对>1kb消息启用deflate压缩。
Webman里广播消息为什么变慢？
因为 Webman 默认用 foreach 遍历所有连接调用 $connection->send()，每条消息都单独序列化、单独写入、单独触发系统调用。1000 个连接 = 1000 次 json_encode() + 1000 次 write()，CPU 和带宽都线性暴涨。
预序列化 + 共享二进制帧怎么写？
适用于消息体基本固定（如系统公告、倒计时、排行榜快照）的场景。核心是把“编码 N 次”变成“编码 1 次 + 复制 N 次”。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 先统一调用
json_encode($data)得到$payload（注意：别传引用或可变数组，避免并发写 panic） - 遍历连接时直接用
$connection->send($payload)，跳过重复编码 - 若需插入 per-connection 字段（如用户昵称），用
str_replace()或preg_replace()替换占位符，而不是重序列化整个结构 - 高频小消息（如心跳、状态 ping）禁用此法——预序列化+复制反而比原生小包更重
Webman 支持 Per-Message Deflate 吗？
支持，但默认关闭。启用后对文本类消息（JSON）压缩率约 40%~70%，但会增加客户端解压负担和服务器 CPU 开销。
- 服务端开启需在 WebSocket 配置中设
'compression' => true（Webman 1.5+） - 仅对 >1KB 的消息启用更合理；
gzip级别不用调太高，Webman 底层基于 Swoole，其 deflate 实现不支持动态字典复用 - 实测发现：含大量重复 key 的 JSON（如
{"uid":123,"ts":172...}）压缩收益明显；纯随机字段（如加密 token）几乎不压缩
广播卡顿还可能是连接管理问题
Webman 默认把所有连接存在内存数组里，连接数过万后遍历本身就成了瓶颈，且无法按 topic 过滤。
- 别依赖
$connections = $server->connections全量广播，改用订阅/发布模式：用 Redis Pub/Sub 中转消息，各 Webman worker 只推送给本机连接 - 连接分片：按
crc32($uid) % 10把用户路由到不同 worker，广播范围从 10w 缩到 1w - 检查是否漏掉
$connection->close()—— 长时间未 close 的连接会堆积缓冲区，导致后续 send 阻塞
