Swoole项目运行缓慢时该如何优化

必须先验证是否真在协程上下文：var_dump(SwooleCoroutine::getPcid())输出false或0即未进入协程，所有I/O将同步阻塞；再启用慢日志与dumpBackTrace定位阻塞点，关闭opcache.validate_timestamps，剥离CPU密集任务至Task Worker，并严禁Windows原生运行。

当Swoole项目在生产环境响应变慢、吞吐骤降、协程挂起不恢复或首请求延迟明显时，必须立即定位阻塞点并切断瓶颈链路，不能依赖“重启观察”或模糊调参。

确认是否真在用协程

第一步不是改配置，而是验证代码是否真正进入协程上下文。在请求入口处插入：var_dump(SwooleCoroutine::getPcid());，若输出为false或0，说明当前执行不在协程内——所有后续I/O操作（数据库、Redis、HTTP）都将以同步阻塞方式运行，Worker进程会立刻卡死。

常见陷阱：用了SwooleHttpServer却未启用协程模式，或启用了但入口函数未被go()包裹；又或者使用了第三方SDK（如Laravel Octane默认未开启协程MySQL），底层仍走PDO同步驱动。

修复方法：确保服务启动时设置'enable_coroutine' => true，且所有耗时I/O调用必须发生在协程内，例如：go(function () { $mysql = new SwooleCoroutineMySQL(); $mysql->connect([...]); });。

排查慢请求的真实源头

不要只看日志里的“超时”，要抓取完整调用栈。

方法一：启用Swoole内置慢日志
在$server->set()中加入：'slowlog' => '/tmp/swoole.slow.log', 'timeout' => 0.5（单位秒）。该配置仅对协程内I/O生效，0.5秒以上未返回的协程将被记录堆栈，含文件名、行号、协程ID及阻塞函数名。

方法二：强制触发全链路追踪
在关键入口添加：SwooleCoroutine::defer(function () { SwooleDebug::dumpBackTrace(); });，配合strace -p [pid] -e trace=epoll_wait,read,write可确认是否卡在系统调用层。

【务必关闭opcache.validate_timestamps = 1】，否则每次文件变更都会触发全量校验，导致协程在require阶段无故挂起数百毫秒。

优化Worker与Task Worker配比

第一步：统计CPU密集型任务占比
若慢请求中超过30%耗时来自图像缩放、JSON序列化大数组、正则匹配长文本等纯计算操作，则必须剥离至Task Worker。

第二步：设置独立Task进程池
$server->set([ 'task_worker_num' => 4, 'task_tmpdir' => '/dev/shm', // 使用内存文件系统避免磁盘IO 'task_max_request' => 5000 ])。

第三步：异步投递不可阻塞主流程
在request回调中调用$server->task($data)，而非$server->taskwait()；Task Worker内禁止调用sleep()、usleep()或任何同步I/O，否则整个Task进程会被锁死。

注意：Task Worker数量不宜超过CPU核心数的1.5倍，否则上下文切换开销反超收益。

禁用Windows原生环境

如果开发机是Windows，且直接运行php server.php，请立刻停止——这不是配置问题，是架构级不可用。

Swoole在Windows下无法使用epoll，退化为select模型，协程调度器每毫秒轮询一次fd，单Worker并发上限不足200；更严重的是，gethostbyaddr等DNS解析调用会阻塞整个进程，且无超时机制。

唯一可行路径：启用WSL2，安装Ubuntu 24.04 LTS，PHP与Swoole全部在WSL2内编译安装，数据库/Redis也部署于同一WSL2实例中，host配置固定为127.0.0.1，禁用所有自动网卡探测逻辑。