Why We Chose Laravel Octane for a 1M-Connection OMS

The constraint of traditional PHP-FPM

Architecting a high-throughput stock exchange Order Management System (OMS) requires supporting extreme concurrency. In financial trading platforms, thousands of institutional clients, algorithmic bots, and retail dashboards maintain persistent connections, expecting sub-millisecond execution reports and order book updates.

Historically, PHP applications operated under the stateless PHP-FPM (FastCGI Process Manager) execution model:

[HTTP Request] ---> [PHP-FPM Worker Spawns] ---> [Boot Laravel Container (15ms)] ---> [Execute Business Logic] ---> [Terminate & Free Memory]

While this share-nothing model guarantees isolation and clean memory state for standard web applications, it becomes an unsustainable bottleneck under exchange load:

1. Repeated Framework Boot Overhead: At 20,000 requests per second, PHP-FPM spends over 80% of CPU cycles repeatedly parsing configuration files, booting service providers, registering routes, and initializing container bindings.
2. Database Connection Saturation: Operating 1,000 FPM workers requires maintaining 1,000 active database connections, exceeding database pool limits and causing connection exhaustion under traffic spikes.
3. Inability to Maintain In-Memory State: FPM cannot persist pre-parsed order books, warm caches, or active socket state in memory across requests without round-trips to external stores like Redis.

What Octane changes: Long-running memory workers

Laravel Octane fundamentally alters PHP's execution paradigm. Powered by high-performance application servers like FrankenPHP or Swoole, Octane boots the Laravel application once into memory upon worker startup:

graph TD
    A["Worker Starts"] --> B["Boot Laravel Container ONCE"]
    B --> C["Request 1: Execute in 0.4ms<br/>(Zero Boot Overhead)"]
    B --> D["Request 2: Execute in 0.3ms"]
    B --> E["Request 3: Execute in 0.4ms"]

By maintaining a pool of long-running worker processes (typically matching CPU core count), Octane eliminates the 15ms framework bootstrap cost entirely, reducing per-request framework overhead to less than 0.1ms.

// Octane worker execution loop conceptual flow
while ($request = $server->accept()) {
    // Application container is already warm in memory
    $response = $app->handle($request);
    $server->send($response);
    
    // Perform state cleanup between requests
    Octane::resetState();
}

The tradeoffs nobody mentions: State leakage & memory management

Operating a long-running PHP application introduces state management challenges that do not exist in traditional PHP-FPM. Because the application state persists in RAM across requests, static variables, singleton bindings, and unmanaged array caches survive between HTTP operations.

The Tenant / User Context Leak Bug

Early in our Octane deployment, we encountered a critical state-leak bug. A singleton TenantContext service held reference to the authenticated client:

// ❌ Dangerous Singleton in Octane
class TenantContext
{
    private ?Client $currentClient = null;

    public function setClient(Client $client): void
    {
        $this->currentClient = $client;
    }

    public function getClient(): ?Client
    {
        return $this->currentClient;
    }
}

In PHP-FPM, $currentClient was automatically garbage-collected at the end of the request. In Octane, if Request B executed on the same worker process as Request A without explicitly setting a new client, Request B inherited Request A's client context!

The Solution: Registering Custom State Resetters

To prevent cross-request state pollution, we configured explicit Octane state resetters in AppServiceProvider:

namespace App\Providers;

use App\Services\TenantContext;
use Illuminate\Support\ServiceProvider;
use Laravel\Octane\Facades\Octane;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        // Force Octane to reset singleton state between requests
        Octane::prepareForNextOperation(function () {
            app(TenantContext::class)->reset();
        });
    }
}

Additionally, we configured FrankenPHP worker auto-restarts (--max-requests=10000) to prevent memory leaks from third-party libraries from causing slow RAM growth over time.

Connection Pooling & Database Scaling

In traditional FPM architectures, handling 1,000,000 concurrent client connections requires horizontal scaling to hundreds of application instances, overwhelming database connection pools.

With Octane, database connection management is vastly more efficient:

1. Persistent Database Connections: Database connections created by Octane workers remain open in memory across requests, eliminating TCP 3-way handshake and TLS negotiation delays on every query.
2. Swoole / FrankenPHP Connection Pools: A small pool of 16 Octane workers can process tens of thousands of concurrent WebSocket events over just 20 persistent PostgreSQL connections.

// Octane configuration in config/octane.php
'warm' => [
    Illuminate\Support\Str::class,
    Illuminate\Cache\Repository::class,
],

'flush' => [
    App\Services\OrderBookCache::class,
],

Production Benchmarks

We benchmarked a 16-vCPU, 32GB RAM cloud instance running our Order Management API endpoints under synthetic load:

Conclusion

Adopting Laravel Octane transformed our OMS infrastructure. By shifting from PHP-FPM's stateless teardown to long-running in-memory workers, we achieved sub-millisecond p99 API latencies and sustained 1M+ concurrent client WebSocket channels on commodity hardware.

While long-running workers demand strict discipline around singleton state resetters and memory management, the performance gains and infrastructure cost savings make Octane an indispensable tool for high-throughput enterprise systems.