Laravel Octane nel 2026: Swoole, RoadRunner e Ottimizzazione delle Performance

Laravel Octane trasforma le performance delle applicazioni PHP mantenendo il framework caricato in memoria tra le richieste. La versione 2.19 (agosto 2026) supporta tre server pronti per la produzione: FrankenPHP, Swoole e RoadRunner. Ognuno soddisfa requisiti operativi differenti, e scegliere quello sbagliato comporta perdite in termini di performance o stabilità.

Come Octane Elimina l'Overhead di Bootstrap

Il tradizionale PHP-FPM genera un nuovo processo per ogni richiesta. Laravel avvia il suo service container, carica la configurazione, registra i provider e risolve i middleware ad ogni singola chiamata HTTP. Octane inverte questo modello: l'applicazione si avvia una volta per worker, poi la stessa istanza gestisce migliaia di richieste in sequenza.

Il guadagno prestazionale deriva dall'eliminazione del lavoro ripetuto. Un'applicazione Laravel 12 tipica impiega da 15 a 40ms per il bootstrap prima di eseguire la logica di business. Con Octane, questo costo scende a zero dopo la prima richiesta. I benchmark su hardware identico mostrano miglioramenti del throughput da 2 a 4 volte per gli endpoint API, con il divario che aumenta all'aumentare della complessità dell'applicazione.

return [
    'server' => env('OCTANE_SERVER', 'frankenphp'),
    
    // I worker gestiscono le richieste HTTP
    'workers' => env('OCTANE_WORKERS', 8),
    
    // Riavvia gracefully i worker dopo N richieste per prevenire il memory bloat
    'max_requests' => env('OCTANE_MAX_REQUESTS', 500),
    
    // Task worker per operazioni concorrenti Swoole
    'task_workers' => env('OCTANE_TASK_WORKERS', 6),
    
    // Tempo massimo di esecuzione per richiesta in secondi
    'max_execution_time' => 30,
];

L'impostazione max_requests funge da valvola di sicurezza. Anche il codice ben scritto può accumulare memoria nel corso di centinaia di richieste. Impostare questo valore a 500 forza i worker a riavviarsi prima che la pressione sulla memoria diventi problematica.

FrankenPHP: Lo Standard del 2026 per i Nuovi Progetti

FrankenPHP viene distribuito come singolo binario costruito su Caddy e PHP. Gestisce automaticamente i certificati HTTPS tramite Let's Encrypt, supporta HTTP/3 nativamente e non richiede l'installazione di estensioni PHP. L'installer di Laravel e gli esempi di produzione ora utilizzano FrankenPHP come default.

# Installa Octane con FrankenPHP
composer require laravel/octane
php artisan octane:install --server=frankenphp

# Avvia il server
php artisan octane:start --server=frankenphp --host=0.0.0.0 --port=8000

Per i deployment containerizzati, FrankenPHP fornisce immagini Docker ufficiali:

# Dockerfile
FROM dunglas/frankenphp

RUN install-php-extensions \
    pcntl \
    pdo_pgsql \
    redis

COPY . /app

ENTRYPOINT ["php", "artisan", "octane:frankenphp"]

La configurazione Docker Compose per lo sviluppo abilita HTTPS e HTTP/3:

# compose.yaml
services:
  frankenphp:
    build:
      context: .
    entrypoint: php artisan octane:frankenphp --workers=1 --max-requests=1
    ports:
      - "443:443"
      - "443:443/udp"
    volumes:
      - .:/app

FrankenPHP gestisce i riavvii dei worker in modo graceful e si integra direttamente con il sistema middleware di Caddy per scenari di routing avanzati.

RoadRunner: Stabilità Basata su Go Senza Dipendenze da Estensioni

RoadRunner compila in un binario Go che gestisce i processi worker PHP. Comunica con PHP attraverso un protocollo binario, mantenendo la gestione dei worker e l'handling HTTP in Go mentre esegue il codice applicativo in PHP. Questa architettura fornisce isolamento dei processi: un worker PHP che crasha non influenza il processo Go parent né i worker fratelli.

# Installa Octane con RoadRunner
composer require laravel/octane spiral/roadrunner-cli spiral/roadrunner-http

php artisan octane:install --server=roadrunner

# Scarica il binario RoadRunner
./vendor/bin/rr get-binary

# Avvia il server
php artisan octane:start --server=roadrunner --host=0.0.0.0 --port=8000

La configurazione di RoadRunner risiede in .rr.yaml nella root del progetto:

# .rr.yaml
version: "3"

server:
  command: "php artisan octane:start --server=roadrunner --host=0.0.0.0 --port=8000"
  relay: pipes

http:
  address: 0.0.0.0:8000
  middleware: ["headers", "gzip"]
  pool:
    num_workers: 8
    max_jobs: 500
    supervisor:
      max_worker_memory: 128

L'impostazione max_worker_memory (in MB) termina i worker che superano i limiti di memoria, fornendo una rete di sicurezza aggiuntiva oltre a max_requests. Per i team con pipeline CI consolidate e infrastruttura PHP-FPM esistente, RoadRunner offre il percorso di migrazione più fluido.

Swoole: Throughput Massimo con Concorrenza Coroutine

Swoole opera come estensione PHP che sostituisce il ciclo di vita standard delle richieste con un runtime event-driven e capace di coroutine. Fornisce funzionalità non disponibili in altri server: esecuzione concorrente di task, tick e intervalli, e una cache in memoria con throughput di 2 milioni di operazioni al secondo.

# Installa Swoole via PECL
pecl install swoole

# Aggiungi a php.ini
echo "extension=swoole.so" >> $(php --ini | grep "Loaded Configuration" | cut -d: -f2 | xargs)/php.ini

# Installa Octane con Swoole
composer require laravel/octane
php artisan octane:install --server=swoole

# Avvia con task worker per operazioni concorrenti
php artisan octane:start --server=swoole --workers=8 --task-workers=6

L'esecuzione concorrente dei task di Swoole gestisce operazioni I/O parallele all'interno di una singola richiesta:

use App\Models\User;
use App\Models\Order;
use App\Models\Analytics;
use Laravel\Octane\Facades\Octane;

class DashboardController extends Controller
{
    public function index()
    {
        // Esegui tre query concorrentemente invece che sequenzialmente
        [$users, $orders, $analytics] = Octane::concurrently([
            fn () => User::active()->count(),
            fn () => Order::today()->sum('total'),
            fn () => Analytics::hourly()->get(),
        ]);

        return view('dashboard', compact('users', 'orders', 'analytics'));
    }
}

Senza Octane::concurrently(), queste tre query vengono eseguite sequenzialmente: 50ms + 30ms + 40ms = 120ms totali. Con l'esecuzione concorrente, il tempo totale equivale alla query più lenta: 50ms. Il flag --task-workers controlla quante operazioni concorrenti possono essere eseguite simultaneamente su tutti i worker di richiesta.

Prevenzione Memory Leak: Scrivere Codice Stateless

Le performance di Octane derivano dallo stato persistente, che crea la sfida principale: il codice che funzionava bene sotto PHP-FPM può causare memory leak catastrofici sotto Octane. L'istanza dell'applicazione sopravvive tra le richieste, quindi proprietà statiche, singleton e stato globale si accumulano.

Tre pattern causano la maggior parte dei memory leak:

Array statici che crescono senza limiti:

// SBAGLIATO: Memory leak - l'array cresce ad ogni richiesta
class MetricsCollector
{
    public static array $data = [];

    public static function record(string $metric): void
    {
        self::$data[] = $metric; // Mai svuotato tra le richieste
    }
}

// CORRETTO: Usa storage con scope di richiesta o sistemi esterni
class MetricsCollector
{
    public function record(string $metric): void
    {
        Redis::lpush('metrics', $metric); // Storage esterno
    }
}

Singleton che mantengono dati specifici della richiesta:

// SBAGLIATO: L'utente della prima richiesta filtra nelle richieste successive
$this->app->singleton(UserContext::class, function ($app) {
    return new UserContext($app['request']->user());
});

// CORRETTO: Usa closure per la risoluzione differita
$this->app->singleton(UserContext::class, function ($app) {
    return new UserContext(fn () => $app['request']->user());
});

Iniezione di container e request nei costruttori:

// SBAGLIATO: Cattura container/request obsoleti
class PaymentService
{
    public function __construct(
        private Application $app,
        private Request $request
    ) {}
}

// CORRETTO: Inietta tramite parametri del metodo o usa helper
class PaymentService
{
    public function processPayment(Request $request): void
    {
        $user = $request->user();
        $config = config('services.stripe.key'); // Helper globale, sempre aggiornato
    }
}

Gli helper globali app(), request() e config() restituiscono sempre valori correnti. Usarli invece dell'iniezione nel costruttore evita la maggior parte dei leak legati ai singleton.

Pattern di Deployment in Produzione

I server Octane necessitano di supervisione dei processi per riavviarsi in caso di crash. Supervisor gestisce questo in modo affidabile:

; /etc/supervisor/conf.d/octane.conf
[program:octane]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan octane:start --server=frankenphp --host=127.0.0.1 --port=8000
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/octane.log
stopwaitsecs=3600

Per i deployment, i worker Octane devono essere ricaricati per acquisire il nuovo codice. Il comando octane:reload gestisce questo in modo graceful, attendendo il completamento delle richieste in corso prima di riciclare i worker:

# Nello script di deployment (dopo git pull, composer install, ecc.)
php artisan octane:reload

Nginx si posiziona davanti a Octane per servire gli asset statici e terminare SSL:

# /etc/nginx/sites-available/app.conf
upstream octane {
    server 127.0.0.1:8000;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name example.com;
    root /var/www/app/public;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        try_files $uri $uri/ @octane;
    }

    location @octane {
        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection "";
        proxy_pass http://octane;
    }
}

La direttiva keepalive mantiene connessioni persistenti tra Nginx e Octane, riducendo l'overhead dell'handshake TCP per le richieste proxied.

Albero Decisionale per la Selezione del Server

La scelta tra FrankenPHP, RoadRunner e Swoole dipende dai vincoli operativi e dai requisiti dell'applicazione:

Per i team che iniziano nuovi progetti nel 2026, FrankenPHP offre il miglior equilibrio tra semplicità e capacità. La migrazione di applicazioni esistenti funziona meglio con RoadRunner grazie al suo isolamento dei processi e al modello di deployment familiare. Swoole è adatto per API ad alto throughput che beneficiano della concorrenza coroutine e richiedono funzionalità specifiche di Swoole.

Domande di Colloquio su Laravel Octane

I colloqui tecnici coprono sempre più Octane man mano che le applicazioni Laravel ad alto traffico lo adottano. Domande comuni e cosa cercano gli intervistatori:

"Come ottiene Octane i suoi guadagni prestazionali?"

La risposta attesa: Octane avvia Laravel una volta per worker e riutilizza quella istanza per le richieste, eliminando il costo di bootstrap di 15-40ms su ogni richiesta. I candidati dovrebbero menzionare che i metodi register e boot dei service provider vengono eseguiti una volta per worker, non per richiesta.

"Cosa causa i memory leak nelle applicazioni Octane?"

Risposte solide identificano tre fonti: array statici che accumulano dati, singleton che catturano stato specifico della richiesta, e iniezione nel costruttore di oggetti container o request. I candidati dovrebbero spiegare che la soluzione prevede l'uso di closure per la risoluzione differita o il passaggio dei dati tramite parametri del metodo.

"Quando sceglieresti Swoole rispetto a RoadRunner?"

I vantaggi di Swoole sono la concorrenza coroutine tramite Octane::concurrently(), la cache Octane ad alta velocità, e funzionalità come tick e intervalli. Il compromesso è la complessità operativa: Swoole richiede la gestione di un'estensione PECL, mentre RoadRunner viene distribuito come binario Go. Per applicazioni CRUD senza necessità di I/O concorrente, RoadRunner è più semplice da gestire.

"Come gestisci i deployment con Octane?"

La sequenza di deployment: smettere di accettare nuove connessioni, attendere il completamento delle richieste in corso, ricaricare i worker con il nuovo codice. Il comando php artisan octane:reload gestisce questo. I candidati dovrebbero menzionare Supervisor o systemd per la supervisione dei processi e Nginx o Caddy come reverse proxy.

Monitoring e Profiling delle Applicazioni Octane

Il monitoring della memoria diventa critico con Octane. I worker sono persistenti, quindi la crescita della memoria indica leak piuttosto che normale overhead di richiesta. Sia Laravel Pulse che Telescope funzionano con Octane e forniscono profiling a livello di richiesta.

use Laravel\Octane\Events\RequestReceived;
use Laravel\Octane\Events\RequestTerminated;

public function boot(): void
{
    Event::listen(RequestReceived::class, function ($event) {
        $event->sandbox->instance('request.memory.start', memory_get_usage());
    });

    Event::listen(RequestTerminated::class, function ($event) {
        $start = $event->sandbox->make('request.memory.start');
        $delta = memory_get_usage() - $start;
        
        if ($delta > 1024 * 1024) { // Più di 1MB di crescita
            Log::warning('Alto delta di memoria', [
                'path' => $event->request->path(),
                'delta_mb' => round($delta / 1024 / 1024, 2),
            ]);
        }
    });
}

Questo event listener registra le richieste che aumentano la memoria di più di 1MB, aiutando a identificare gli endpoint che necessitano di ottimizzazione. Per il monitoring in produzione, strumenti APM esterni come Datadog o New Relic forniscono visibilità a livello di worker.

Integrazione di Octane con Code e Horizon

Octane gestisce le richieste HTTP; Laravel Horizon gestisce i worker delle code. I due operano indipendentemente e si completano a vicenda. L'elaborazione pesante appartiene ai job in coda, mantenendo i worker Octane reattivi.

use App\Jobs\GenerateReport;

class ReportController extends Controller
{
    public function generate(Request $request)
    {
        // Invia alla coda invece di bloccare il worker Octane
        GenerateReport::dispatch($request->user(), $request->input('parameters'));

        return response()->json(['status' => 'processing']);
    }
}

Punti Chiave su Laravel Octane nel 2026

• Octane 2.19 supporta tre server: FrankenPHP (più semplice), RoadRunner (più stabile) e Swoole (più funzionalità)
• I guadagni prestazionali derivano dall'eliminazione del bootstrap per richiesta; aspettarsi miglioramento del throughput da 2 a 4 volte
• I memory leak si verificano perché lo stato del worker persiste; evitare array statici, request iniettate nel costruttore e singleton con dati di richiesta
• Usare --max-requests=500 per forzare il riciclo dei worker prima che la pressione sulla memoria aumenti
• Le funzionalità solo Swoole includono Octane::concurrently(), tick, intervalli e la cache Octane
• Deployare dietro Nginx o Caddy con Supervisor per la gestione dei processi
• Profilare la crescita della memoria per richiesta; delta superiori a 1MB indicano potenziali leak
• Mettere in coda il lavoro pesante tramite Horizon; riservare i worker Octane per risposte HTTP veloci