Workerman高并发响应慢需多进程优化：仅Linux/macOS支持有效多进程，Windows仅模拟；count须在Worker实例创建后、runAll前设置；根据CPU/IO密集度合理设值，并启用reusePort提升吞吐，同时依RSS内存估算安全count上限。
Workerman服务在高并发下响应变慢、CPU使用率低但请求排队堆积，说明当前单进程无法吃满硬件资源，必须通过正确配置多进程释放多核性能。
确认运行环境是否支持多进程
先执行 php -r "echo PHP_OS;" 查看系统类型——只有 Linux 或 macOS 才能真正启用多进程；Windows 下设置 $worker->count 无效，只会启动单进程并用线程模拟，稳定性与隔离性均不达标。
【必须在 Linux/macOS 服务器上操作，Windows 开发机仅作代码调试，不可用于生产部署】
再运行 uname -r 检查内核版本，若低于 3.9，则后续启用 reusePort 会失败。
设置 count 参数的正确位置和写法
Worker 实例创建后、Worker::runAll() 调用前，直接赋值 $worker->count。
错误写法（完全无效）：
在 onWorkerStart 回调里写 $worker->count = 8，此时进程已 fork 完毕，赋值毫无作用。
正确写法示例：
$worker = new Worker('http://0.0.0.0:8080');<br>$worker->count = 4;
注意：每个 Worker 实例（如 Gateway、BusinessWorker、TimerWorker）都需单独设置 count，不能共用一个变量。
根据业务类型确定 count 值
第一步：用 nproc 查出物理 CPU 核心数，例如返回 4。
第二步：判断业务倾向性——
方法一：CPU 密集型（图像缩放、大量数学计算、协程内同步阻塞调用）→ 设为 核心数 或 核心数 + 1，比如 4 核设 $worker->count = 4 或 5。
方法二：IO 密集型（频繁 mysqli_query、file_get_contents、curl 同步请求）→ 设为 核心数 × 3～5，4 核建议从 12 起压测，可设 12、16 或 20。
方法三：混合型（既有计算又有外部 API 调用）→ 先设 核心数 × 2（如 4 核设 8），然后观察 top 中各 PHP 进程的 %CPU：若普遍长期低于 30%，说明 IO 等待多，可加 count；若多数 > 80% 且 ss -lnt | grep :端口 显示 Recv-Q 持续堆积，说明 CPU 已饱和，再加无益。
启用 reusePort 提升连接分发效率
在设置 count 后、Worker::runAll() 前，追加一行：$worker->reusePort = true;
启用后，操作系统内核直接将新连接轮询分发给空闲 Worker 进程，避免主进程 accept 队列锁竞争，实测同配置下吞吐量可提升 10–20%。
验证是否生效：运行 ss -lnt | grep :8080，若同一端口出现多行输出（如 4 行），说明每个 Worker 进程都独立监听成功。
【若 ss 命令无多行输出，检查 PHP 版本是否 ≥ 7.0、内核是否 ≥ 3.9、transport 是否为 tcp/http，默认 stream_socket_server 支持 SO_REUSEPORT】
控制内存不爆掉的关键估算
不要依赖理论值，用真实 RSS 内存反推安全上限：先以 $worker->count = 2 启动服务，等稳定后执行 ps aux --sort=-%mem | grep php | head -5，取单个 Worker 进程的 RSS 值（单位 KB），比如看到 48236 → 约 47MB。
服务器总内存为 16GB（16384MB），按 80% 可用率计算：16384 ÷ 47 × 0.8 ≈ 278 → 最大安全 count 不要超过 270。
压测时若 free -h 显示可用内存持续跌破 500MB，或 dmesg | tail 出现 Out of memory: Kill process，说明已触达内存瓶颈，必须降低 count 或优化单进程内存占用。
