Webman 与 Laravel+RoadRunner 的性能差异

这组结果和直觉基本一致：请求越简单，常驻内存带来的优势越明显；一旦接口开始频繁访问数据库，差距会收窄，但 Webman 还是更省内存，也更稳一点。

架构层面的差别

1. 架构层次对比

2. 内存使用模式

// Webman 内存使用（常驻）
$app = require_once __DIR__.'/bootstrap/app.php'; // 框架只加载一次，后续请求直接使用

// Laravel + RoadRunner
// 每个 Worker 独立加载完整 Laravel 框架
// 内存 = Worker 数量 × Laravel 内存占用

内存占用对比：

• Webman: 框架 45MB + 业务内存（共享）
• Laravel + RoadRunner: 4 Workers × 80MB = 320MB

3. 请求处理流程对比

Webman 处理流程

请求 → Workerman 事件循环 → 路由解析 → 控制器 → 响应
↑_____________________
↓ 内存中完成，无重复加载

Laravel + RoadRunner 处理流程

请求 → Go RoadRunner → PHP Worker 进程 → Laravel 启动 → 路由 → 控制器 → 响应
↑__________________________________________________________
↓ 每次请求都需要重新初始化 Laravel 容器

这里的核心差异其实不复杂：Webman 把'启动框架'这件事摊薄到进程生命周期里，Laravel + RoadRunner 则是把 Laravel 尽量留在 Worker 里复用。后者已经比 FPM 轻很多，但和前者那种常驻模型比，还是多了一层成本。

细项性能表现

1. CPU 使用率对比

RoadRunner 这边的 Go-PHP 进程间通信会带来额外 CPU 开销，这也是它在高并发下更容易先碰到天花板的原因。

2. 连接处理能力

# 长连接测试 wrk -t10 -c1000 -d60s --timeout 30s http://localhost:8080

3. 静态文件服务性能

// Webman 静态文件（使用 sendfile）
$response->file('/path/to/file'); 

// Laravel 静态文件
return response()->file('/path/to/file');

这类场景里，Webman 的优势会被放大，因为它更接近'直接把文件交给底层系统处理'的思路。Laravel + RoadRunner 不是不能做，只是没必要拿它去和专门擅长长连接和静态资源的方案硬拼。

实际业务场景

1. API 网关场景

// 模拟 API 网关：认证 + 转发 + 日志
Route::get('/api/proxy/{service}', function ($service) {
    // 1. JWT 认证
    $user = Auth::validate(request()->token);
    // 2. 请求转发
    $response = HttpClient::post("http://{$service}", request()->all());
    // 3. 记录日志
    Log::info("API 调用", ['service' => $service, 'user' => $user->id]);
    return $response;
});

2. 微服务通信场景

// 微服务间通信（HTTP + Redis）
class OrderService {
    public function createOrder($data) {
        // 调用用户服务
        $user = $this->userService->getUser($data['user_id']);
        // 调用库存服务
        $this->inventoryService->lockStock($data['items']);
        // 创建订单
        $order = Order::create($data);
        // 发布事件
        Redis::publish('order_created', json_encode($order));
        return $order;
    }
}

如果业务里主要是网关转发、聚合接口、长连接推送这类活儿，Webman 会更顺手。Laravel + RoadRunner 更适合已经在 Laravel 生态里、又想尽量把性能往上抬一截的团队；它不是最轻的路子，但迁移成本通常没那么难看。

配置优化对比

1. Webman 优化配置

// config/server.php
return [
    'listen' => 'http://0.0.0.0:8787',
    'transport' => 'tcp',
    'context' => [],
    'process' => [
        'monitor' => [
            'enable' => true,
            'max_memory' => 128, // MB
            'check_interval' => 60,
        ],
    ],
    'worker_num' => 4, // CPU 核心数
    'reloadable' => true,
    'reusePort' => true, // 端口复用
    'event_loop' => \Workerman\Events\Event::class,
];

2. Laravel + RoadRunner 优化配置

# .rr.yaml
version: "3"
server:
  command: "php artisan roadrunner:serve"
  relay: "pipes"
  relay_timeout: "60s"
http:
  address: ":8080"
  pool:
    num_workers: 4
    max_jobs: 1000
supervise:
  enabled: true
  max_worker_memory: 128
rpc:
  listen: "tcp://127.0.0.1:6001"
logs:
  mode: "production"

这两套配置都不复杂，但调法不一样。Webman 更像是在调一个常驻服务，重点在 worker、内存和事件循环；RoadRunner 则更像在管一个 PHP Worker 池，重点是 worker 生命周期和资源回收。前者偏底层，后者偏框架迁移友好。

怎么选

如果你追求的是极致吞吐、长连接、低内存占用，Webman 更合适。它的优势不是'PHP 也能很快'这种空话，而是它的运行模型本来就更贴近高并发服务的需求。

如果你的项目已经深度绑定 Laravel，团队也离不开它的生态，Laravel + RoadRunner 是更现实的折中。它能把性能抬上去不少，只是别指望用同样的代码路径换来同样的架构收益。