webman支撑rtb需调优io模型、进程调度与内核参数：worker数设为cpu核数×3（如8核设24），同步调优sysctl网络参数，并启用event扩展；禁用同步io，改用异步redis/http调用，日志异步化；上线前验证内存波动、孤儿连接及上下文切换。
Webman 能撑住实时竞价（RTB）系统的毫秒级响应和万级并发，但直接套用默认配置必崩——关键不在框架本身，而在 IO 模型、进程调度和内核参数的三重对齐。
为什么 RTB 场景下 Webman 的默认 $worker->count 会失效
RTB 请求特征是短连接 + 高频 + 强依赖外部服务（DSP 接口、用户画像 Redis、出价规则 DB），属于典型的 IO 密集型负载。默认按 CPU 核数设 $worker->count（比如 4 核设为 4）会导致：
- Worker 进程数太少，连接堆积在内核队列，
netstat -s | grep "packet receive errors"计数飙升 - 单个 Worker 处理多个请求时，遇到 Redis 查询或 HTTP 调用就阻塞，无法及时响应后续 bid request
- 实际压测中 QPS 卡在 2000 左右，CPU 利用率却只有 30%，说明不是算力瓶颈，而是调度/IO 瓶颈
必须改的三个核心配置项
不调这三项，再多优化都是隔靴搔痒：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
-
config/bootstrap.php中调整 Worker 数量：IO 密集型场景起步用cpu_count() * 3，例如 8 核服务器设为24；实测 RSS 平均值若达 45MB，则硬上限为(64 * 1024) ÷ 45 × 0.8 ≈ 1150，向下取整得最大安全值115 -
/etc/sysctl.conf同步调优内核参数：net.core.somaxconn = 65535、net.ipv4.tcp_max_syn_backlog = 65535、net.core.netdev_max_backlog = 30000；执行sudo sysctl -p生效 -
start.php中启用 event 扩展（非必须但强烈建议）：确认已安装php-event，并在Worker::$eventLoopClass显式指定EventLoop\ExtEventLoop::class，否则 fallback 到 select/poll，epoll 优势无法释放
bid request 处理链路上最容易卡死的点
RTB 对端到端延迟敏感，以下环节一旦同步阻塞，整个 Worker 就废了：
- Redis 连接未设
timeout=0.05，单次超时 1 秒 → 直接拖垮该 Worker 当前所有待处理请求 - 调 DSP 接口用
file_get_contents()或 cURL 同步方式 → 必须换成Workerman\Connection\AsyncTcpConnection或support\HttpClient的异步调用 - 出价逻辑里用了
sleep()、usleep()或未加锁的全局变量计数 → 触发竞态或人为延迟，违反 RTB 的确定性要求 - 日志写入未异步化：
error_log()或file_put_contents()直接落盘 → 改用support\Log并配置rotate+async模式
上线前必须验证的三件事
很多团队跑通功能就上线，结果首波流量就丢 bid —— 不是代码问题，是环境没对齐：
- 用
ps aux --sort=-%mem | grep php抓 5 个稳定运行的 Worker，确认 RSS 波动不超过 ±15%，否则内存泄漏已在发生 - 用
ss -s查看inuse和orphans是否同步上升；若orphans持续 > 100，说明 Worker 处理不过来，要降并发或查慢逻辑 - 用
vmstat 1 10观察cs（上下文切换）是否超过 CPU 核数 × 1000；超了说明进程调度过载，$worker->count真的设高了
RTB 系统的性能天花板从来不由 PHP 代码决定，而由 Worker 进程数、单进程 RSS、内核网络参数这三者的交集决定——少盯任意一环，压测数据都不可信。
