总体结论与定位
在 CentOS 上，ThinkPHP 的并发能力主要取决于运行模式（PHP-FPM 传统模式 vs Swoole 常驻内存协程模式）、代码与数据库优化程度以及是否做了缓存、负载均衡等系统工程。工程实践中，优化良好的 PHP-FPM + Nginx 单体通常可达约数百至数千 QPS；引入 Swoole/协程 与连接池后，吞吐可进一步提升，有实战路线从100 → 10000 QPS；第三方对比显示 ThinkPHP8 在常见读场景下的并发表现处于中等水平，而 Go 在高并发与计算密集场景更占优。另有文章声称官方测试可达**>10000 QPS**，但此类数据高度依赖场景与硬件，需谨慎参考。
不同运行模式下的并发表现
| 运行模式 |
并发特点 |
典型场景 |
预期吞吐 |
| PHP-FPM + Nginx（传统模式） |
每个请求由进程/线程处理，短生命周期；受 pm.max_children、数据库/缓存等后端瓶颈影响 |
常规业务、内容展示、表单提交 |
优化良好时约数百–数千 QPS |
| Swoole HTTP Server（常驻内存 + 协程） |
框架与数据库连接常驻内存，协程非阻塞 I/O，连接复用，减少进程频繁创建开销 |
长连接、WebSocket、高并发 API、异步任务 |
吞吐较 FPM 模式常见提升8–10 倍；配合多级缓存与队列可达万级 QPS的实战目标 |
| 上述结论来自工程实践与公开案例，具体数值仍取决于业务复杂度与基础设施能力。 |
|
|
|
影响并发的关键瓶颈与优化要点
- PHP 运行时与 OPcache
- 开启并合理设置 opcache（如：opcache.enable=1、opcache.memory_consumption、realpath_cache_size），关闭 APP_DEBUG，减少文件 I/O 与编译开销。
- Nginx 与静态资源
- 合理配置 worker_processes/worker_connections，启用 gzip，对静态资源设置长缓存并尽量走 CDN，降低后端压力。
- PHP-FPM 进程模型
- 结合内存与 CPU 调整 pm.max_children/pm.start_servers/pm.min_spare_servers/pm.max_spare_servers，避免进程争用与排队。
- 数据库与缓存
- 建立有效索引、避免 N+1 查询、分页优化；引入 Redis 多级缓存与热点数据预热；读写分离、必要时分库分表；使用连接池减少连接开销。
- 异步与队列
- 将耗时任务（邮件/短信/图片处理/日志）放入队列（如 Redis/Database 驱动），削峰填谷，提升请求响应与稳定性。
- 多实例与负载均衡
- 多台 Nginx + PHP-FPM 实例配合 Nginx 负载均衡，会话共享（如 Redis），实现水平扩展与高可用。
快速自测与容量规划
- 明确业务场景（读多写少/写密集/是否含文件 I/O/是否长连接），构造贴近真实的压测脚本（如 wrk/ab/jmeter），分别压测 FPM 与 Swoole 两套环境。
- 记录关键指标：P95/P99 延迟、QPS、错误率、CPU/内存、PHP-FPM 队列、数据库连接数、慢查询；逐步调大并发，观察拐点与瓶颈点。
- 以“目标 QPS × 平均响应时间”估算并发连接需求，并反向校核 PHP-FPM pm.max_children、Nginx worker_connections、数据库连接池大小与缓存命中率，留出安全余量。
