OpenSwoole: O PHP que Continua Vivo Entre as Requisições

A maioria dos desenvolvedores PHP programa assumindo uma verdade absoluta:

"Quando a resposta é enviada ao navegador, todo o estado da aplicação desaparece."

Com OpenSwoole, essa verdade deixa de existir.

Durante décadas, o PHP foi conhecido por um modelo de execução extremamente simples: uma requisição chega, o script é executado e, ao final, toda a memória utilizada é descartada.

Esse comportamento fez parte da identidade da linguagem e influenciou diretamente a forma como milhões de aplicações foram desenvolvidas. Frameworks, bibliotecas e até padrões de projeto assumem que cada requisição começa em um ambiente completamente limpo.

Mas esse modelo também possui um custo.

A cada requisição, o PHP precisa:

• Inicializar a aplicação.
• Carregar classes.
• Criar conexões.
• Montar o container de dependências.
• Executar todo o processo novamente.

Mesmo com recursos como o OPcache reduzindo parte desse trabalho, ainda existe um custo considerável para reconstruir o ambiente da aplicação inúmeras vezes por segundo.

É justamente esse paradigma que o OpenSwoole propõe mudar.

Em vez de executar um script do início ao fim para cada requisição, o OpenSwoole mantém um servidor PHP permanentemente em execução. A aplicação é inicializada apenas uma vez e continua viva, pronta para atender milhares de requisições consecutivas.

Mas o ganho não se resume à performance.

Ao mudar o ciclo de vida da aplicação, o OpenSwoole também muda a forma como o desenvolvedor precisa pensar sobre estado, memória, concorrência e arquitetura.

Neste artigo, vamos entender como ele funciona e por que essa mudança de paradigma exige alguns cuidados que simplesmente não existem no PHP tradicional.

Como o PHP tradicional funciona

Em um ambiente convencional (Apache + mod_php, PHP-FPM ou CGI), cada requisição é completamente independente das demais.

Imagine um usuário acessando uma página:

Cliente
    │
    ▼
PHP inicia
    │
Carrega o autoload
    │
Inicializa o framework
    │
Executa seu código
    │
Envia a resposta
    │
Libera toda a memória

Quando a resposta é enviada ao navegador, praticamente tudo é destruído.

Isso significa que:

• Objetos deixam de existir.
• Variáveis são descartadas.
• Singletons desaparecem.
• O container de dependências é destruído.
• Toda a memória utilizada é liberada.

Na próxima requisição, o processo inteiro acontece novamente.

É justamente esse comportamento que torna alguns códigos naturalmente seguros.

Por exemplo:

class RequestCounter
{
    private int $count = 0;

    public function increment(): int
    {
        return ++$this->count;
    }
}

$counter = new RequestCounter();

echo $counter->increment();

Independentemente de quantas vezes o usuário atualize a página, o resultado será sempre:

1

Isso acontece porque um novo objeto é criado em toda requisição.

Outro exemplo:

class Cache
{
    private array $items = [];

    public function put(string $key, mixed $value): void
    {
        $this->items[$key] = $value;
    }

    public function get(string $key): mixed
    {
        return $this->items[$key] ?? null;
    }
}

No PHP tradicional, esse cache só existe durante a execução da requisição.

Assim que a resposta é enviada, tudo desaparece.

Por isso, durante muitos anos, desenvolvedores PHP praticamente nunca precisaram se preocupar com memória persistente ou compartilhamento de estado entre requisições.

O que muda com OpenSwoole

O OpenSwoole muda completamente esse ciclo de vida.

Em vez de executar um script para cada requisição, ele inicia um servidor que permanece em execução.

O fluxo passa a ser algo semelhante a isto:

Servidor inicia
        │
Carrega Composer
        │
Inicializa framework
        │
Cria objetos
        │
────────────────────────────
        │
Requisição 1
        │
Requisição 2
        │
Requisição 3
        │
Requisição 4
        │
...

Observe que a aplicação não é reconstruída a cada acesso.

Ela permanece viva na memória.

Isso significa que objetos criados durante a inicialização continuam existindo até que o servidor seja reiniciado ou o processo seja reciclado.

Um exemplo simples ajuda a visualizar essa diferença.

<?php

$counter = 0;

$server = new OpenSwoole\Http\Server('127.0.0.1', 9501);

$server->on('request', function ($request, $response) use (&$counter) {
    $counter++;

    $response->end("Requisição número {$counter}");
});

$server->start();

Se você acessar:

http://localhost:9501

A primeira resposta será:

Requisição número 1

Atualizando a página:

Requisição número 2

Depois:

Requisição número 3

No PHP tradicional isso seria impossível utilizando uma variável comum.

Ela seria destruída ao final de cada requisição.

No OpenSwoole ela permanece em memória.

É justamente esse comportamento que torna possível reduzir drasticamente o tempo gasto com bootstrap da aplicação.

Ao mesmo tempo, surge uma nova responsabilidade: evitar que dados de uma requisição permaneçam disponíveis para outra.

É por isso que aplicações desenvolvidas para OpenSwoole precisam ter muito cuidado com:

• propriedades estáticas;
• singletons com estado;
• variáveis globais;
• caches em memória;
• objetos reutilizados.

Esses elementos deixam de existir apenas durante uma única requisição e passam a permanecer vivos enquanto o processo estiver em execução.

Instalando o OpenSwoole

O OpenSwoole é distribuído como uma extensão nativa do PHP, portanto não basta instalá-lo via Composer.

A forma mais comum é utilizando o PECL:

pecl install openswoole

Depois, habilite a extensão no php.ini:

extension=openswoole

Você pode verificar se tudo foi instalado corretamente executando:

php -m | grep openswoole

Ou:

php --ri openswoole

Se a extensão estiver carregada, o PHP exibirá informações como versão, recursos habilitados e opções de compilação.

Um servidor HTTP em poucas linhas

Após instalar a extensão, criar um servidor HTTP é surpreendentemente simples:

<?php

use OpenSwoole\Http\Request;
use OpenSwoole\Http\Response;
use OpenSwoole\Http\Server;

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

$server->on('request', function (
    Request $request,
    Response $response
) {
    $response->header('Content-Type', 'text/plain');

    $response->end("Olá, OpenSwoole!");
});

$server->start();

Execute o arquivo normalmente:

php server.php

O terminal permanecerá ocupado, pois agora quem está rodando é um servidor HTTP completo.

Basta acessar:

http://127.0.0.1:9501

E a resposta será:

Olá, OpenSwoole!

Esse pequeno exemplo já demonstra a principal diferença em relação ao PHP tradicional: o script não termina após atender uma requisição. Ele continua em execução, aguardando a próxima conexão. É justamente esse modelo que permite ao OpenSwoole oferecer recursos como corrotinas, WebSockets, timers, tarefas assíncronas e um desempenho muito superior ao modelo tradicional de requisição por processo.

O erro que quase todo mundo comete

Quem começa a usar OpenSwoole normalmente continua programando como sempre fez em PHP. Afinal, a linguagem é a mesma, o framework pode ser o mesmo e grande parte do código continua funcionando.

O problema é que algumas práticas que eram completamente seguras no PHP tradicional deixam de ser.

O erro mais comum é assumir que objetos permanecem isolados entre as requisições.

Imagine o seguinte serviço:

class UserService
{
    private ?User $currentUser = null;

    public function setUser(User $user): void
    {
        $this->currentUser = $user;
    }

    public function getCurrentUser(): ?User
    {
        return $this->currentUser;
    }
}

No PHP tradicional isso raramente causa problemas.

A cada requisição, um novo objeto é criado e destruído ao final da execução.

No OpenSwoole, porém, esse objeto pode continuar vivo na memória.

Imagine a seguinte sequência:

Requisição A
────────────

$currentUser = João

↓

Resposta enviada

↓

Objeto continua existindo


Requisição B
────────────

$currentUser = ?

Se esse serviço for compartilhado entre múltiplas requisições (por exemplo, como um singleton), existe o risco de o próximo usuário encontrar dados que pertenciam ao anterior.

Esse tipo de situação recebe o nome de vazamento de estado (state leak).

Outro exemplo bastante comum são propriedades estáticas:

class Counter
{
    public static int $requests = 0;
}

Counter::$requests++;

echo Counter::$requests;

No PHP tradicional, a resposta será sempre:

1

Já no OpenSwoole:

1
2
3
4
5
...

A propriedade nunca é reinicializada entre as requisições.

O mesmo cuidado vale para:

• variáveis globais;
• caches implementados em arrays;
• objetos armazenados em singletons;
• conexões compartilhadas incorretamente;
• qualquer estrutura que mantenha estado em memória.

Isso não significa que essas técnicas estejam proibidas.

Significa apenas que agora elas realmente permanecem vivas.

Outro ponto importante é que o OpenSwoole executa múltiplas requisições simultaneamente utilizando corrotinas. Embora elas sejam muito mais leves que threads, duas corrotinas ainda podem acessar o mesmo objeto ao mesmo tempo se ele for compartilhado inadequadamente.

Em outras palavras: o OpenSwoole aproxima o PHP do modelo utilizado por plataformas como Java, Go, .NET e Node.js, onde a aplicação permanece em execução por longos períodos e a memória precisa ser tratada com muito mais cuidado.

Então OpenSwoole é perigoso?

Não.

Na verdade, ele apenas remove uma "proteção" que o modelo tradicional do PHP oferecia automaticamente.

Durante muitos anos, o ciclo de vida curto das requisições escondia diversos problemas de arquitetura. Como tudo era destruído ao final da execução, era praticamente impossível um objeto sobreviver tempo suficiente para causar efeitos colaterais.

No OpenSwoole, isso deixa de acontecer.

Mas isso não é um defeito.

É justamente assim que funcionam servidores escritos em:

• Java (Spring Boot);
• ASP.NET;
• Go;
• Node.js;
• Rust (Axum, Actix, etc.).

Nenhuma dessas plataformas recria toda a aplicação a cada requisição.

O PHP apenas passa a seguir esse mesmo modelo.

Na prática, basta adotar algumas boas práticas:

• Evite armazenar dados da requisição em propriedades de objetos compartilhados.
• Prefira serviços stateless sempre que possível.
• Utilize variáveis locais para informações específicas da requisição.
• Não abuse de propriedades estáticas.
• Compartilhe apenas recursos realmente compartilháveis, como pools de conexões, caches globais e configurações.

Frameworks modernos também ajudam bastante nesse aspecto. Projetos como Laravel Octane já foram adaptados para funcionar corretamente sobre OpenSwoole, tomando diversos cuidados internamente para evitar vazamentos de estado.

Portanto, o OpenSwoole não torna sua aplicação mais frágil.

Ele apenas exige uma disciplina arquitetural que outras plataformas já exigem há muitos anos.

O que ele entrega em troca

Essa mudança de paradigma traz benefícios que vão muito além da redução do tempo de resposta.

Como a aplicação permanece carregada em memória, o custo de inicialização praticamente desaparece.

Em vez de reconstruir todo o framework para cada requisição, o servidor simplesmente reutiliza o ambiente já existente.

Isso reduz significativamente o trabalho repetitivo realizado pelo PHP.

Além disso, o OpenSwoole oferece recursos que normalmente exigiriam ferramentas externas ou arquiteturas muito mais complexas.

Corrotinas

As corrotinas permitem executar operações de I/O de forma concorrente sem criar múltiplas threads.

Imagine uma API que precisa consultar três serviços externos.

No PHP tradicional:

API A → espera

↓

API B → espera

↓

API C → espera

Com corrotinas:

API A ─┐
        ├── executam simultaneamente
API B ─┤
        │
API C ─┘

Na prática:

use OpenSwoole\Coroutine;

Coroutine\run(function () {
    Coroutine::create(function () {
        echo "Consultando API A...\n";
    });

    Coroutine::create(function () {
        echo "Consultando API B...\n";
    });

    Coroutine::create(function () {
        echo "Consultando API C...\n";
    });
});

Embora esse exemplo apenas imprima mensagens, em um cenário real cada corrotina poderia realizar uma requisição HTTP, consultar um banco de dados ou acessar um serviço externo. Como essas operações são predominantemente de I/O, executá-las de forma concorrente reduz o tempo total de espera.

WebSockets nativos

Criar servidores WebSocket passa a ser uma tarefa extremamente simples.

Isso permite desenvolver aplicações em tempo real, como:

• chats;
• notificações;
• dashboards;
• jogos online;
• monitoramento de sistemas;
• colaboração em documentos.

Sem precisar adicionar servidores especializados para esse tipo de comunicação.

Servidor HTTP de alta performance

O próprio OpenSwoole implementa um servidor HTTP otimizado.

Você não depende mais do PHP-FPM para atender requisições.

Isso reduz a sobrecarga do modelo tradicional baseado em processos.

Timers

Também é possível executar tarefas periódicas diretamente dentro da aplicação.

Por exemplo:

use OpenSwoole\Timer;

Timer::tick(5000, function () {
    echo "Executando a cada 5 segundos...\n";
});

Esse recurso é útil para:

• limpeza de caches;
• sincronizações;
• coleta de métricas;
• processamento de filas;
• monitoramento de recursos.

Tudo isso sem depender de um cron.

Processamento assíncrono

O OpenSwoole também facilita a criação de workers e tarefas em segundo plano.

Isso permite mover operações demoradas para processamento assíncrono, como:

• envio de e-mails;
• geração de PDFs;
• processamento de imagens;
• importação de arquivos;
• integração com APIs externas.

Enquanto isso, o usuário recebe a resposta imediatamente.

Maior aproveitamento do hardware

Como as corrotinas são extremamente leves, um único processo consegue manter milhares de conexões simultâneas.

Isso reduz a quantidade de processos necessária para atender um grande volume de usuários e melhora o aproveitamento de CPU e memória, principalmente em aplicações com muito I/O.

No fim, esse é talvez o maior benefício do OpenSwoole: ele transforma o PHP em uma plataforma capaz de executar aplicações modernas, concorrentes e de longa duração, mantendo a produtividade que tornou a linguagem tão popular. Ele não substitui o PHP tradicional em todos os cenários, mas amplia significativamente o tipo de problema que a linguagem consegue resolver com eficiência.

Conclusão

Durante muito tempo, o PHP foi associado a um modelo simples: receber uma requisição, executar o código e encerrar o processo. Esse paradigma tornou o desenvolvimento mais intuitivo e ajudou a popularizar a linguagem, mas também estabeleceu algumas premissas que muitos desenvolvedores passaram a considerar imutáveis.

O OpenSwoole quebra justamente uma dessas premissas.

Ao manter a aplicação viva em memória, ele elimina boa parte do custo de inicialização, oferece recursos como corrotinas, WebSockets, timers e processamento assíncrono, além de permitir que aplicações PHP atinjam níveis de desempenho e concorrência antes reservados a outras plataformas.

Por outro lado, essa mudança exige uma nova forma de pensar. Objetos deixam de ser descartados ao final de cada requisição, estados podem permanecer em memória e boas práticas arquiteturais passam a ser ainda mais importantes.

A boa notícia é que esse modelo não é uma novidade no mundo do desenvolvimento. Linguagens e plataformas como Java, Go, .NET e Node.js já funcionam dessa maneira há muitos anos. O OpenSwoole apenas leva o PHP para esse mesmo patamar, preservando a sintaxe e o ecossistema que tornaram a linguagem uma das mais utilizadas no desenvolvimento web.

Isso significa que o OpenSwoole não é uma substituição obrigatória para todas as aplicações. Muitos projetos continuarão funcionando perfeitamente sobre PHP-FPM ou Apache. Entretanto, quando o objetivo é construir APIs de alta performance, aplicações em tempo real ou sistemas com grande volume de conexões simultâneas, ele se torna uma alternativa extremamente interessante.

No fim das contas, aprender OpenSwoole não significa apenas conhecer uma nova extensão do PHP. Significa compreender um modelo diferente de execução e perceber que a linguagem evoluiu muito além do tradicional "executa e termina". Para quem deseja explorar todo o potencial do PHP moderno, esse é um conhecimento que certamente vale o investimento.

Aprender OpenSwoole não significa apenas aprender uma biblioteca.

Significa abandonar uma premissa que acompanha o PHP desde os anos 90.

E, talvez justamente por isso, ele seja uma das tecnologias mais interessantes do ecossistema PHP atualmente.