webman性能远超laravel，源于常驻内存架构与fpm模式的本质差异：实测qps达laravel(fpm)的31倍、laravel+roadrunner的5–8倍，但需配连接池、禁debug、用异步i/o，否则易因连接耗尽或同步阻塞导致压测失败。

Webman 的性能不是“比 Laravel 快一点”，而是架构代际差——它不走 PHP-FPM，没有每次请求重载框架、重建容器、重复自动加载的开销。实测 QPS 是 Laravel(FPM) 的 31 倍、Laravel + RoadRunner 的 5–8 倍。

为什么 Webman 压测 QPS 高得离谱？

根本原因不在代码写得有多精简，而在进程生命周期：Webman 启动后常驻内存，onWorkerStart 只执行一次；Laravel(FPM) 每次请求都得从 index.php 重新加载全部框架类、重建 Container、解析配置、注册中间件……光自动加载就可能吃掉 10–20ms。

实测数据（4 核 8GB，PHP 8.2）：

• 纯 API 接口：webman QPS 45,678 vs laravel + roadrunner QPS 8,912
• 数据库密集接口（10 次查询）：webman QPS 1,234 vs laravel + roadrunner QPS 567
• 内存占用：webman 峰值 85MB，laravel + roadrunner 峰值 350MB

onWorkerStart 里初始化 DB/Redis 会炸吗？

会，而且很常见。很多人把 onWorkerStart 当成 Laravel 的 AppServiceProvider::boot() 用，直接 new PDO() 或 new Redis()，结果压测时 Connection refused 或 Too many open files 频出。

关键点：

laravel-specialist

精通 Laravel 10+，遵循现代 PHP 实践的 Laravel 专家。擅长优雅语法、Eloquent ORM、队列系统及企业级特性...

下载

• onWorkerStart 是进程级的：16 个 worker 就可能独占 16 个 MySQL 连接；MySQL 默认 max_connections=151，8 个 worker × 每个 10 连接 = 80，再加后台任务就打满了
• Redis 同理：redis-cli info clients | grep connected_clients 看真实连接数，别信客户端“自动释放”
• 必须上连接池：用 workerman/mysql 替代原生 PDO，或接入 hyperf/database 协程驱动
• 全局状态不能靠普通静态变量：每个 worker 进程内存独立，A::count++ 在 B 进程里完全不可见

数据库慢查询让整个 worker 卡死？

是的。Webman 默认仍是同步阻塞模型——哪怕你开了 16 个 worker，一个没加索引的 SELECT * 查了 2 秒，整个进程就卡住，后续请求全排队。

这不是配置问题，是调用方式问题：

• 原生 pdo_mysql、mysqli、think-orm 全是同步的，和 FPM 时代没区别
• 要真正发挥 Webman 并发能力，必须切换异步 I/O：用 workerman/mysql 客户端，或 hyperf/database + 协程 MySQL 驱动
• 别指望“开了多 worker 就能扛住慢 SQL”——worker 数量只解决 CPU 并行，不解决 I/O 阻塞

选型时最容易被忽略的硬伤

性能数字很诱人，但 Webman 不是 Laravel 的“高性能开关”。它没有服务容器、没有门面、没有自动依赖注入、没有 php artisan 命令体系。你写 app()->make(UserService::class) 得自己引入 illuminate/container，路由参数绑定、中间件注入、事件监听全得手动接。

这意味着：

• 团队熟悉 Laravel 生态？迁移成本远不止改几行 Route::get
• 需要快速搭管理后台？Webman 没有现成的 CRUD 生成器，得自己拼组件
• 想用 Eloquent？可以，但连接池、软删除钩子、模型事件在常驻进程下行为和 FPM 不同，得重验
• 压测失败第一反应不该是加 worker->count，而应查 ulimit -n、netstat -an | grep :8787 | wc -l、show processlist