webman吞吐量瓶颈源于常驻进程下资源失控：内存持续上涨、连接池溢出、gc失效、静态缓存失控；需主动控制生命周期，而非仅调配置。

Webman 吞吐量上不去，不是框架不行，而是常驻进程下资源没管住——内存持续上涨、连接池溢出、GC 失效、静态缓存失控，这些才是真实瓶颈。调优不是堆配置，是控制生命周期。

Webman 内存越跑越高怎么压住

Worker 进程不重启，memory_get_usage() 就只涨不跌；gc_collect_cycles() 在循环引用场景下基本无效，比如模型关联 + 事件监听器互相持有，或者 use ($request) 把整个请求对象塞进定时器回调里。

• 每次请求结束前，显式 unset($bigArray)、unset($content)，别等 GC
• 数据库查大列表时禁用 all()，改用 cursor() 或 chunk(500)
• 静态缓存类（如 Cache::set('key', $data)）必须配 TTL 或手动 forget()，禁用永久缓存
• 返回大响应体时，用 response()->stream() + yield 流式输出，避免一次性 json_encode($hugeList)

数据库连接池配置不合理导致阻塞

默认连接池最大连接数太小，高并发下请求排队；设太大又浪费内存、触发 MySQL 的 max_connections 限制。关键不是“够不够”，是“要不要一直占着”。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

• 在 config/database.php 中调整 pool.max_connections，建议设为预估峰值并发的 1/3～1/5（例如 QPS 3000，连接池设 600～1000）
• pool.min_connections 设为 1～3，避免冷启动延迟；pool.wait_timeout 控制空闲连接回收时间，设 3～5 秒较稳妥
• 确认业务代码没漏掉 $pdo->close() 或未释放的查询句柄，尤其在异常分支中

Worker 进程数与 reusePort 配置失衡

单 Worker 处理能力再强，也扛不住连接分发不均。Linux 默认的 accept() 竞争模型在多核下会造成惊群和排队，reusePort 不开等于白搭。

• 在 start.php 中设置 $worker->count = cpu_count() * 2，但别超过 32（太多进程反而调度开销大）
• 务必开启 $worker->reusePort = true，让内核做负载分发，而不是靠用户态抢锁
• 若用 Nginx 反向代理，确保 upstream 配置了 least_conn 或 ip_hash，避免单个 Webman Worker 被打爆

OPcache 和 PHP 运行时配置被忽略

Webman 是常驻进程，但 PHP 解析器本身仍会反复加载文件——如果 OPcache 关着，每个请求都在重复编译，性能直接打五折。

• opcache.enable=1 必须开；opcache.validate_timestamps=0 生产环境必设（开发环境可设为 1 + opcache.revalidate_freq=2）
• opcache.memory_consumption 至少设 128，项目含大量组件时建议 256
• realpath_cache_size 设为 4096K，realpath_cache_ttl 设为 600，减少路径解析开销
• 禁用 display_errors，开启 log_errors，避免错误信息刷屏干扰性能观测

真正卡住吞吐量的，往往不是某个开关没开，而是多个生命周期管理点同时失控：一次请求里 new 了大对象、塞进静态缓存、又没关数据库游标、还开着 OPcache 验证……这些细节叠加起来，比少开一个 reusePort 影响更大。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！