webman支撑实时大屏必须采用常驻内存+协程模型，因其单worker可并发处理数百sse/长轮询连接，避免fpm模式每请求启进程、反复加载与销毁的性能损耗；需守护进程启动、禁用阻塞操作、启用连接池、流式压缩响应、全局单例registry、预聚合指标并同步调优redis/mysql/nginx配置。
Webman 要支撑实时大屏，必须用常驻内存 + 协程模型
传统 PHP-FPM 模式每请求启进程、加载类、查库、关连接，根本扛不住大屏的高频轮询（比如每秒 10+ 次 /api/metrics）。Webman 的常驻内存 + 协程天然适配：单 Worker 进程可并发处理数百个 SSE 或长轮询连接，内存不反复抖动，CPU 利用率平稳。
关键点：
- 确保
start.php启动方式为php start.php start -d（守护进程），不是每次请求 reload； - 禁用所有阻塞操作：
mysql_connect()、file_get_contents()、sleep()必须换成协程版（如co::sleep()、Db::query()）； - 大屏数据源若来自 Redis 或 MySQL，务必启用连接池（如
webman/redis或webman/database的 pool 配置），避免连接耗尽； - 不要在控制器里
echo json_encode()后直接exit—— 这会 kill 掉整个 Worker 进程。
/api/dashboard 返回 JSON 必须流式压缩且带 Cache-Control
大屏前端通常用 fetch() 或 axios 每 2–5 秒拉一次最新指标，如果每次响应都未压缩、无缓存控制，Nginx 和客户端会反复建连、传冗余 payload，拖慢整体刷新节奏。
实操建议：
- 在路由中间件中统一开启 Gzip：
$response->withHeader('Content-Encoding', 'gzip')，并确保 Nginx 开启gzip on； - 设置强缓存头：
$response->withHeader('Cache-Control', 'no-cache, no-store, must-revalidate')—— 看似矛盾，但这是防止浏览器缓存旧数据的关键； - 避免在响应体里拼接 HTML 或混入调试
var_dump()，大屏 JS 对 JSON 格式极其敏感，多一个空格或换行就会JSON.parse()失败； - 如果返回字段较多（如含设备列表、告警聚合、趋势数组），先用
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)减少体积。
SSE 推送告警事件时 registry 必须全局单例
很多团队用 SSE 实现“告警弹窗”或“状态灯闪烁”，但一上线就发现事件漏发、重复推、连接断连后无法重续 —— 根子在 CollectorRegistry 被重复 new。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
典型错误写法：new CollectorRegistry() 放在控制器 index() 里，或放在中间件 handle() 中；
正确做法：
- 在
app/Bootstrap.php最顶部初始化：$GLOBALS['metrics_registry'] = new CollectorRegistry();； - SSE 路由（如
/api/alerts/stream）中只调$registry = $GLOBALS['metrics_registry']，再$counter->inc()或$gauge->set($value)； - 务必检查
Content-Type: text/event-stream响应头是否被其他中间件覆盖（特别是 CORS 中间件）； - 每个 SSE 连接需维持心跳：
event: heartbeat\ndata: ping\n\n，间隔不超过 30 秒，否则 Nginx 默认 60 秒断连。
大屏指标聚合逻辑不能放数据库 GROUP BY
当大屏要展示“过去 5 分钟每秒请求数”或“各服务 P95 延迟”，如果每次请求都走 MySQL 的 GROUP BY FROM_UNIXTIME(create_time, '%Y-%m-%d %H:%i:%s')，IO 和 CPU 会瞬间打满，Worker 进程卡死。
更稳的路径是：
- 用 Redis Sorted Set 或 Time Series（如 RedisTimeSeries 模块）预存采样点，SSE 路由只做
ZRANGEBYSCORE拉取； - 后台起一个
Timer自定义进程（见app/Process/StatsAggregator.php），每 1 秒从日志或中间件埋点消费原始耗时，聚合后写入 Redis； - 避免在 Webman 请求周期内做
array_map()+array_reduce()处理上万条原始数据 —— 协程虽轻量，但 CPU 密集型操作仍会阻塞整个 Worker； - 前端大屏 JS 应自带降级逻辑：若某次 API 返回 503 或超时，沿用上一次有效数据，并显示“数据延迟 xx 秒”提示。
真实压测中，Worker 进程数设为 CPU 核数 × 1.5 是较稳妥起点；但最终瓶颈往往不在 PHP 层，而在 Redis 连接数、MySQL max_connections 或 Nginx worker_connections 配置上——这些得同步盯紧。
