Performance

Async PHP and Swoole: Building High-Concurrency Apps

Use Swoole and PHP fibers to build concurrent applications. Covers coroutines, connection pooling, WebSockets, and production deployment.

Swoole coroutine concurrency diagram with PHP code

PHP was designed for the request-response model: a request arrives, PHP processes it, sends a response, and the process dies. This model is simple and eliminates entire categories of bugs around state management. But it also means every request pays the cost of bootstrapping the application, and concurrent I/O requires awkward workarounds.

Swoole changes this by turning PHP into a long-running process with coroutine-based concurrency. Your PHP code can now handle thousands of concurrent connections, run parallel database queries, and serve WebSocket connections—all from a single process.

What Swoole provides

Swoole is a PHP extension (written in C++) that adds:

  • Coroutines: Lightweight green threads that yield during I/O
  • Async I/O: Non-blocking database, HTTP, file, and Redis clients
  • HTTP server: Replaces Nginx + php-fpm entirely
  • WebSocket server: Native WebSocket support
  • Task workers: Offload heavy computation without blocking the event loop
  • Connection pooling: Reuse database and Redis connections across requests

Installation

1
2
3
4
5
6
7
8
# Via PECL
pecl install swoole

# Or compile from source
git clone https://github.com/swoole/swoole-src.git
cd swoole-src
phpize && ./configure --enable-openssl --enable-http2
make && make install

Add to php.ini:

1
extension=swoole

Coroutines: the core concept

A coroutine is a function that can pause execution while waiting for I/O and resume when the I/O completes. This is different from threading—coroutines share a single thread and switch cooperatively.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
use Swoole\Coroutine;

Coroutine\run(function () {
    // These two coroutines run concurrently
    Coroutine::create(function () {
        // Fetch user data (I/O — coroutine yields here)
        $client = new Swoole\Coroutine\Http\Client('api.example.com', 443, true);
        $client->get('/users/1');
        echo "User: " . $client->body . "\n";
    });

    Coroutine::create(function () {
        // Fetch order data concurrently
        $client = new Swoole\Coroutine\Http\Client('api.example.com', 443, true);
        $client->get('/orders/recent');
        echo "Orders: " . $client->body . "\n";
    });
});

Both HTTP requests happen concurrently. When one coroutine is waiting for a network response, the other runs. Total time is roughly equal to the slowest request, not the sum of both.

How this differs from JavaScript async/await

In JavaScript, you explicitly await promises. In Swoole, I/O functions automatically yield the coroutine. You write synchronous-looking code, and Swoole makes it concurrent:

1
2
3
4
5
6
7
8
9
10
// This looks synchronous but is actually concurrent under Swoole
function getUserWithOrders(int $userId): array
{
    $user = DB::table('users')->find($userId);      // yields during query
    $orders = DB::table('orders')
        ->where('user_id', $userId)
        ->get();                                      // yields during query

    return ['user' => $user, 'orders' => $orders];
}

Under php-fpm, those two queries run sequentially. Under Swoole, if you wrap them in separate coroutines, they run concurrently.

Building an HTTP server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
use Swoole\Http\Server;
use Swoole\Http\Request;
use Swoole\Http\Response;

$server = new Server('0.0.0.0', 9501);

$server->set([
    'worker_num' => swoole_cpu_num(),
    'max_request' => 10000,     // Restart worker after N requests (prevents memory leaks)
    'enable_coroutine' => true,
]);

$server->on('request', function (Request $request, Response $response) {
    $path = $request->server['request_uri'];

    if ($path === '/api/users') {
        $users = queryUsers(); // Coroutine-aware DB call
        $response->header('Content-Type', 'application/json');
        $response->end(json_encode(['data' => $users]));
        return;
    }

    $response->status(404);
    $response->end('Not Found');
});

$server->start();

This server handles thousands of concurrent connections on a single machine. Each request runs in a coroutine, so I/O-bound operations (database queries, external API calls) do not block other requests.

Connection pooling

Without pooling, each coroutine opens a new database connection. With 1,000 concurrent requests, you would exhaust MySQL’s connection limit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
use Swoole\Database\PDOConfig;
use Swoole\Database\PDOPool;

$pool = new PDOPool(
    (new PDOConfig())
        ->withHost('127.0.0.1')
        ->withPort(3306)
        ->withDbName('myapp')
        ->withUsername('root')
        ->withPassword('secret')
        ->withCharset('utf8mb4'),
    size: 64  // Max 64 connections
);

// In a request handler
$pdo = $pool->get();       // Borrow a connection
$stmt = $pdo->query('SELECT * FROM users LIMIT 10');
$users = $stmt->fetchAll();
$pool->put($pdo);          // Return connection to pool

With Laravel Octane

Laravel Octane manages connection pooling automatically:

1
php artisan octane:start --server=swoole --workers=4 --task-workers=6

Octane resets the application state between requests and manages connection lifecycle. This is the recommended approach for Laravel projects.

WebSocket server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
use Swoole\WebSocket\Server;
use Swoole\WebSocket\Frame;

$ws = new Server('0.0.0.0', 9502);

$ws->on('open', function (Server $server, $request) {
    echo "Connection opened: {$request->fd}\n";
});

$ws->on('message', function (Server $server, Frame $frame) {
    $data = json_decode($frame->data, true);

    // Broadcast to all connected clients
    foreach ($server->connections as $fd) {
        if ($server->isEstablished($fd)) {
            $server->push($fd, json_encode([
                'user' => $frame->fd,
                'message' => $data['message'],
                'timestamp' => time(),
            ]));
        }
    }
});

$ws->on('close', function (Server $server, int $fd) {
    echo "Connection closed: {$fd}\n";
});

$ws->start();

This is a complete WebSocket chat server in PHP. No Node.js, no external dependencies.

Common mistakes

Not resetting state between requests: Static variables, global state, and class-level caches persist across requests in Swoole. If you store a user object in a static property during request #1, it is still there during request #2.

1
2
3
4
5
6
7
8
9
10
// BUG: state leaks between requests
class AuthService
{
    private static ?User $currentUser = null;

    public static function setUser(User $user): void
    {
        self::$currentUser = $user; // Persists across requests!
    }
}

Using blocking I/O libraries: Standard PHP functions like file_get_contents work but block the event loop when used outside coroutine context. Use Swoole’s coroutine clients or wrap blocking calls in Coroutine::create().

Ignoring memory leaks: In php-fpm, memory leaks do not matter because the process dies after each request. In Swoole, a process handles thousands of requests. Small leaks accumulate. Use max_request to periodically restart workers.

Production deployment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# docker-compose.yml
services:
  app:
    image: php:8.4-cli
    volumes:
      - .:/app
    command: php /app/server.php
    ports:
      - "9501:9501"
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9501/health"]
      interval: 30s
      timeout: 5s
      retries: 3

Monitoring

Monitor these metrics in production:

  • Coroutine count (should not grow unbounded)
  • Connection pool utilization
  • Worker memory usage over time
  • Request processing time percentiles

When to choose Swoole vs. alternatives

Need Swoole FrankenPHP php-fpm ReactPHP
High concurrency ✅ Best Good Adequate Good
WebSockets ✅ Native No No ✅ Native
Framework support Laravel, Symfony Laravel All Limited
Learning curve Steep Moderate None Moderate
Hosting flexibility VPS/container only VPS/container Everywhere VPS/container

FAQ

Can I use Swoole with WordPress?

Not practically. WordPress relies heavily on global state and blocking I/O patterns that conflict with Swoole’s coroutine model.

Is Swoole or OpenSwoole better?

Swoole (upstream) has more active development and wider community support as of 2026. OpenSwoole diverged in 2021 and has a different roadmap. Choose based on which is more actively maintained when you evaluate.

Do I need to rewrite my application for Swoole?

If you use Laravel Octane, no. Octane handles the adaptation layer. For custom applications, you need to audit state management and replace blocking I/O calls.

Next steps

Start with Laravel Octane + Swoole if you are on Laravel. For other frameworks, install the Swoole extension and build a minimal HTTP server to understand coroutine behavior before porting your application.

The FrankenPHP guide covers an alternative high-performance runtime that is easier to adopt. For API design patterns that benefit from Swoole’s concurrency, see the REST API best practices guide.