webman的$worker->count应据业务类型设定：io密集型建议cpu核数×3–5，cpu密集型设为cpu核数或+1；需按实测rss内存估算上限，并预留20%余量，再通过压测与监控动态调优。
Webman的$worker->count到底该设多少
不是“CPU核数×2”就安全，也不是“越多越好”。Webman底层是Workerman，它的count本质是常驻PHP进程数，每个进程独占一份内存、独立事件循环。设高了直接OOM；设低了CPU空转、连接排队。
关键看业务类型：
- 用
mysqli、pdo_mysql、redis->get()等**阻塞调用**——IO密集型，count建议从CPU核数 × 3起步（如4核→12），压测中可试到×5 - 用
Webman\Support\AsyncMysql、Redis::coroutine()或纯计算逻辑——CPU密集型，count设为CPU核数或CPU核数 + 1更稳 - 混用场景？先设
CPU核数 × 2，再用ps aux --sort=-%mem | grep php看真实RSS，结合top里各PHP进程的%CPU持续值判断倾向
内存才是count的硬上限，不是CPU
每个Webman Worker进程启动后常驻内存约30–60MB，取决于加载的类库、是否启用opcache、日志级别、中间件数量。别信“空进程才几MB”这种估算。
快速估算最大安全count：
最大安全count ≈ (总内存GB × 1024) ÷ 单进程RSS(MB) × 0.8
例如：16GB内存服务器，实测单Worker RSS为48MB → 16 × 1024 ÷ 48 × 0.8 ≈ 273，那就别设超过270。线上必须用ps aux --sort=-%mem | grep php抓3–5个稳定运行的Worker取平均RSS，不能靠文档预估。
reusePort = true能多开几个进程吗
能，但只多10–20%，且有前提条件。
$worker->reusePort = true;解决的是内核层“惊群”问题，让新连接哈希分发到不同Worker，减少无效唤醒。它不降低单进程内存，也不绕过IO/CPU瓶颈。
开启后count可微调提升，比如原设24，可试28；但若已逼近内存上限，开reusePort毫无意义，还会因内核哈希表膨胀略微增加延迟。
务必确认：uname -r ≥ 3.9，PHP ≥ 7.0，且stream_socket_server()底层支持SO_REUSEPORT（低版本PHP会静默忽略）。
Webman里改count的实际位置在哪
不在config/目录下，而是在start.php或start_gateway.php这类启动文件里。
常见误操作：在config/server.php里配count——那只是框架配置项，不生效；真正起作用的是Worker实例上的属性。
正确写法示例：
use Webman\Worker;
$worker = new Worker('http://0.0.0.0:8787');
$worker->count = cpu_count() * 3; // 或写死数字，如12
// 注意：必须在Worker::runAll()前设置
如果用了Gateway/BusinessWorker架构（如IM服务），要分别调优GatewayWorker和BusinessWorker的count，两者比例建议1:1或1:2，避免网关接入快、业务处理堵住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
