FrankenPHP内置Mercure单机稳定承载3000–5000长连接，超限易触发connection reset、断连或OOM；其性能受Go runtime调度、系统fd限制（需设ulimit -n 65536）、goroutine开销及客户端行为模式共同制约。
FrankenPHP 自带的 Mercure 服务单机稳定承载约 3,000–5,000 个长连接，超出后容易出现 connection reset、eventsource 断连或内存持续增长导致 OOM。
Mercure 连接数受制于 Go runtime 和系统 fd 限制
Mercure 在 FrankenPHP 中不是独立进程，而是作为 Caddy 插件嵌入 Go 主循环，所有连接由 Go 的 net/http.Server 管理。它不依赖 PHP worker，但共享同一进程的文件描述符（fd）和 goroutine 调度器。
- 默认 ulimit -n 为 1024，
frankenphp启动时若未显式调高，实际能建的连接远低于 1000；必须在启动前执行ulimit -n 65536并写入 systemd service 的LimitNOFILE=65536 - Go 的 HTTP/2 server 对每个连接维持至少 2 个 goroutine（读 + 写），当并发连接超 4000，goroutine 数轻松破万，调度开销明显上升，
runtime: goroutine stack exceeds 1GB limit错误开始出现 - Mercure 的 eventsource 响应是 chunked transfer encoding 流式输出，连接不关闭就一直占着 fd 和内存 —— 每个活跃连接平均吃掉 1.2–1.8 MB RSS 内存（实测 PHP 应用常驻模式下）
连接数不是纯数字问题，要看客户端行为模式
真实压测中，连接数上限高度依赖客户端是否“真长连”：如果大量客户端只是建立连接后静默挂起（比如移动端后台保活），FrankenPHP 可以撑到 4500+；但如果每秒有数百客户端反复 connect/disconnect（如弱网重试），连接回收跟不上，netstat -an | grep :80 | wc -l 显示 TIME_WAIT 爆满，实际有效连接可能跌到 2000 以下。
- 避免客户端使用短轮询模拟长连：
new EventSource('/.well-known/mercure?topic=...')必须配合服务端 keep-alive，不能靠前端 setInterval 重建连接 - Mercure 的
publish频率直接影响压力：单次 publish 向 3000 个客户端广播，会触发 3000 次 write() 调用，此时 CPU 往往先于内存成为瓶颈（top中frankenphp进程 %CPU > 90%） - 启用
mercure.publish.origin并配置 CDN 回源，可把大量空闲连接卸载到边缘节点，本地只保留活跃推送链路
如何验证当前实例的真实上限
不要只看 curl -s http://localhost:2019/metrics | grep mercure_connections 返回的瞬时值 —— 它只统计已注册的连接，不反映底层资源水位。
立即学习“PHP免费学习笔记（深入）”；
- 监控关键指标：
process_open_fds（接近LimitNOFILE就危险）、go_goroutines（持续 > 15000 需警惕）、mercure_subscribers_total（突降说明连接被内核强制回收） - 用
ss -s查看 socket 统计：重点关注tcp行的estab和time-wait数量比，若后者 > 前者 3 倍，说明连接复用失败 - 最直接的压力测试命令：
hey -z 5m -q 10 -c 2000 'http://localhost/.well-known/mercure?topic=foo'（注意：-c 是并发连接数，不是 QPS）
真正卡住性能的往往不是连接总数，而是 publish 事件的扇出效率和客户端网络质量分布。上线前务必用真实设备群做混合压测，而不是只跑 ab 或 hey —— 很多断连问题在模拟器里根本复现不出来。
