背景与动机

大带宽服务器（例如轻云互联的100Mbps独享带宽）能轻松扛住数万并发连接，但PHP应用本身的I/O模型往往成为瓶颈。很多开发者误以为堆带宽就能提升并发，实则同步阻塞模型（如Apache prefork+mod_php）在1000并发下就会耗尽进程资源。本文使用同一台轻云互联大带宽服务器（8核16G，SSD），对三种经典PHP架构进行极端压测：Nginx+PHP-FPM（同步阻塞）、Swoole（异步回调）、Hyperf（协程）。所有测试均针对CPU密集型（计算阶乘）和I/O密集型（模拟100ms外部API调用）两种场景，只贴真实数据和配置代码。

测试环境与工具

# 服务器信息
OS: Ubuntu 22.04 LTS
Kernel: 5.15.0-91-generic
CPU: Intel Xeon E5-2683 v4 @ 2.1GHz (8核)
内存: 16GB DDR4
网络: 轻云互联独享100Mbps

# 压测工具
ab -n 100000 -c 2000 -k http://test.php
wrk -t4 -c2000 -d60s http://test.php

PC端发包机同样为轻云互联同机房内网机器，排除网络抖动。

架构一：Nginx+PHP-FPM (static模式)

配置

# /etc/php/8.1/fpm/pool.d/www.conf
pm = static
pm.max_children = 200
pm.max_requests = 500

# /etc/nginx/sites-available/default
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_buffer_size 8k;
    fastcgi_buffers 32 8k; # 大带宽下需要放大buffer
}

测试PHP脚本：CPU密集型

<?php
$n = 100;
$result = factorial($n);
function factorial($n) {
    return $n <= 1 ? 1 : $n * factorial($n-1);
}
echo $result;

压测结果（CPU密集）

• 并发2000，持续60s
• Requests/sec: 1847
• 平均延迟: 85ms (最差120ms)
• CPU使用率: 98% (user 45%, sys 53%)
• 内存: PHP-FPM进程占用~1.2GB (每个子进程6MB)

出现大量TIME_WAIT，但带宽只用了30Mbps，瓶颈在CPU上下文切换（sys高）。

架构二：Swoole (异步回调)

启动代码

<?php
use Swoole\Server;
$server = new Server("0.0.0.0", 9501, SWOOLE_PROCESS);
$server->set([
    'worker_num' => 8,
    'reactor_num' => 8,
    'backlog' => 8192,
    'max_conn' => 10000,
    'dispatch_mode' => 2,
    'open_tcp_nodelay' => true,
]);
$server->on('Receive', function ($server, $fd, $reactor_id, $data) {
    $n = 100;
    $result = factorial($n);
    $server->send($fd, $result);
});
function factorial($n) {
    return $n <= 1 ? 1 : $n * factorial($n-1);
}
$server->start();

压测结果（CPU密集）

• wrk -t4 -c2000 -d60s http://server:9501/
• Requests/sec: 4231
• 平均延迟: 23ms (最差80ms)
• CPU使用率: 100% (user 75%, sys 25%)，系统调用大幅减少
• 内存: 240MB (8个worker + 8个reactor)

吞吐量是PHP-FPM的2.3倍，但注意Swoole的Worker进程内无阻塞，单次请求计算后直接返回，无进程创建开销。

架构三：Hyperf (协程，基于Swoole)

关键配置

# config/autoload/server.php
return [
    'mode' => SWOOLE_PROCESS,
    'servers' => [
        [
            'name' => 'http',
            'type' => Style::SERVER_HTTP,
            'host' => '0.0.0.0',
            'port' => 9502,
            'sock_type' => SWOOLE_SOCK_TCP,
            'callbacks' => [
                Event::ON_REQUEST => [Hyperf\HttpServer\Server::class, 'onRequest'],
            ],
        ],
    ],
    'settings' => [
        'enable_coroutine' => true,
        'worker_num' => 4, // 协程下worker更少，利用协程并行
        'max_coroutine' => 30000,
    ],
];

控制器代码

<?php
use Hyperf\HttpServer\Annotation\Controller;
use Hyperf\HttpServer\Annotation\RequestMapping;

#[Controller]
class TestController
{
    #[RequestMapping(path: '/test', methods: 'get')]
    public function test()
    {
        $n = 100;
        // 协程内计算，但CPU密集型无需协程切换
        $result = factorial($n);
        return $result;
    }
}

压测结果（CPU密集）

• wrk -t4 -c2000 -d60s http://server:9502/test
• Requests/sec: 4587
• 平均延迟: 21ms
• CPU使用率: 99% (user 80%, sys 19%)
• 内存: 260MB

协程在CPU密集场景无优势，略高于纯Swoole回调，因调度开销略大。但差距不大。

I/O密集型场景对比

将脚本改为模拟外部API调用（sleep 0.1秒）：

# PHP-FPM版本
usleep(100000); // 0.1s

# Swoole版本（异步）
$server->tick(100, function() use ($server, $fd) {
    $server->send($fd, "done");
}); // 模拟非阻塞接口

# Hyperf版本（协程）
use Hyperf\Utils\Coroutine;
Co::sleep(0.1); // 挂起协程

结果对比

大带宽服务器在I/O密集时优势明显：PHP-FPM因进程池限制，带宽闲置95%；而Swoole/Hyperf几乎占满100Mbps（约12MB/s响应数据）。

关键优化参数（大带宽适配）

针对大带宽服务器的瓶颈往往在内核网络栈，调优必不可少：

# /etc/sysctl.conf 追加
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_congestion_control = bbr
net.core.netdev_budget = 600
net.core.netdev_budget_usecs = 4000

同时在Nginx中放大proxy buffer（见上文配置），避免上游阻塞在慢客户端。

总结与选型建议

• CPU密集+大带宽：Swoole/Hyperf均可，QPS提升2-3倍，但配置复杂度高，需监控内存泄漏。
• I/O密集（如多API调用、数据库查询）：放弃PHP-FPM，直接上协程，QPS提升10倍以上。
• 轻云互联的大带宽服务器本身能扛住NAT、高连接数，但应用层若不优化，带宽白白浪费。
• 推荐生产级方案：Hyperf + Nginx反向代理，利用协程和连接池，再配合OPcache+JIT，可逼近C++级别吞吐。

最后给出一个性能基线命令，用于自测：

wrk -t8 -c10000 -d120s --latency http://your-domain/test
# 观察90%延迟是否超过200ms，CPU的sys%是否超过30%

调优无止境，但大带宽服务器配上正确的PHP架构，才能榨干每一兆带宽。