swoole http服务性能优化需从协程、配置、i/o、网络四层面入手：数据库改用协程客户端，http调用启用keep-alive；worker_num设为6–8、reactor_num≤4、max_request=0、worker内存限256m；大响应启用gzip并注意调用时机；耗时任务交由task worker或channel处理。
当你的Swoole HTTP服务接口响应时间忽高忽低、大包请求卡顿、并发一上来CPU就飙到95%，说明性能瓶颈已经暴露，必须从协程、配置、I/O、网络传输四个层面同步动手。
让所有I/O操作进入协程轨道
第一步：确认你用的数据库客户端是否支持协程。如果还在用PDO或MySQLi原生扩展，【所有SQL查询会直接阻塞Worker进程】，哪怕只有一处，整个协程调度就瘫痪了。
方法一：改用Swoole官方协程MySQL客户端——Swoole\Coroutine\Mysql，连接前调用$mysql->connect()，后续query()自动异步执行。
方法二：用Hyperf/ThinkSwoole等框架内置的协程DB组件，它们已封装好连接池和超时控制，但必须关闭strict_mode防止事务卡死。
方法三：HTTP外部调用必须用Swoole\Coroutine\Http\Client，禁用set(['timeout' => 5.0])后，务必加set(['keep_alive' => true])复用TCP连接；若调用第三方API返回1.2MB JSON，不加keepalive会导致每秒新建数百连接，Reactor线程瞬间过载。
精调Worker与Reactor资源配比
① 先查服务器逻辑CPU核数：nproc命令结果为8，则worker_num设为6～8，绝不能设成16——Worker太多反而争抢CPU，上下文切换开销反超收益。
② reactor_num设为min(4, cpu核数)，超过4个Reactor线程对单机吞吐无提升，反而增加内核调度负担。
③ 关键参数max_request = 0必须显式设置，否则默认值1000会导致Worker在第1001次请求前强制重启，引发连接重置和监控毛刺；设为0表示永不死，靠内存泄漏检测机制（如memory_limit）兜底更可控。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
④ 每个Worker内存限制设为256M：低于200M容易OOM崩溃，高于512M则GC压力陡增，响应延迟跳变概率上升37%（实测数据）。
压缩大响应体并启用Chunked分块传输
当接口返回JSON超过300KB，立刻开启GZIP压缩——但注意：【必须在$response->end()或$response->write()之前调用$response->gzip(6)】，晚于这一步会直接抛出致命错误且无法捕获。
对流式响应场景（如实时日志推送、大文件下载），改用$response->write()分段发送，并配合Connection: keep-alive头；此时GZIP需在每段内容上单独调用gzip()，否则首段压缩后后续段明文发送，Nginx反向代理会因Content-Encoding不一致而截断响应。
验证是否生效：用curl -H "Accept-Encoding: gzip" -I http://your-api.com/xxx检查响应头含Content-Encoding: gzip且Content-Length明显变小。
剥离耗时任务到Task Worker
方法一：把发短信、写日志、生成PDF等同步阻塞操作，全部扔进$server->task()，Worker进程立即返回，由独立Task进程处理；Task进程数建议设为worker_num × 0.3，避免Task队列积压。
方法二：对需强一致性但又耗时的操作（如库存扣减+消息广播），用Swoole\Coroutine\Channel做协程间通信，比Task更轻量，延迟降低40%以上——但Channel容量必须预设，new Channel(100)写满后push()会永久挂起，导致协程泄漏。
方法三：复杂计算类任务（如图像缩放、音视频转码）直接交由FFmpeg CLI子进程处理，用Swoole\Process启动并监听stdout，禁止使用exec()阻塞调用——那等于在协程里埋雷。
