DEV Community: Jeferson Guedes

PHP-FPM/JIT vs FrankenPHP Worker vs Swoole: um benchmark honesto com Symfony

Jeferson Guedes — Tue, 09 Jun 2026 16:55:20 +0000

TL;DR — Para CPU puro, o que importa é o JIT, e FPM empata com FrankenPHP. Para leitura, os runtimes persistentes voam (até 3,5× o FPM). Para escrita, FrankenPHP lidera, mas o Swoole expõe contenção de conexão. E o erro mais comum em benchmark de runtime é comparar configurações com número de workers diferente.

Por que fiz isso

Toda discussão sobre "PHP moderno é rápido" esbarra na mesma confusão: as pessoas comparam runtimes (FPM, FrankenPHP, Swoole) mas mudam dezenas de variáveis ao mesmo tempo — versão do PHP, JIT ligado/desligado, número de processos, framework, banco. O resultado é inconclusivo.

A proposta aqui foi isolar a variável runtime: o mesmo código Symfony, o mesmo PHP 8.4 com Opcache + JIT, o mesmo MySQL 8, mudando só como o PHP é executado.

Os três cenários

#	Arquitetura	Stack	Porta
1	Clássico tunado	Nginx + PHP-FPM (Opcache + JIT `1255`, Unix socket)	8081
2	Moderno worker	Traefik + FrankenPHP (Worker Mode)	8182*
3	Assíncrono	Traefik + Swoole	8083

* A :8082 original estava ocupada por um processo local na minha máquina, então o FrankenPHP foi publicado na 8182.

Todos compartilham o mesmo app/ Symfony — o que muda é só a imagem Docker e o modo de execução. Endpoints de teste:

GET /bench/cpu-bound — contagem de primos + hashes bcrypt (CPU puro, sensível ao JIT)
GET /bench/io-read — SELECT dos 20 registros mais recentes → JsonResponse
GET /bench/io-write — INSERT + flush(), devolve o ID gerado

A pegadinha que quase invalidou tudo

Na primeira rodada, os workers estavam desbalanceados: FPM com pm.max_children=16 e FrankenPHP/Swoole com 4 workers cada. Resultado "de fábrica":

Endpoint	FPM (16w)	FrankenPHP (4w)	Swoole (4w)
io-read	1.654	4.085	4.099
io-write	919	680	644
cpu-bound	27	21	11

Parece que o FPM "ganha" em escrita e CPU — mas isso é viés de paralelismo: com 64 conexões batendo numa tarefa de CPU, o FPM processa 16 em paralelo e os outros só 4. Não é o runtime, é a contagem de processos.

Lição: num benchmark de runtime, iguale o número de workers. Senão você está medindo pm.max_children, não a arquitetura.

O comparativo justo (4 workers em todos)

Baixei o FPM para pm.max_children=4 e repeti — 64 conexões concorrentes, 12s por medição, com warmup descartado:

Throughput (req/s — maior é melhor)

Endpoint	FPM+JIT	FrankenPHP	Swoole	Vencedor
cpu-bound	19,7	19,7	14,4	empate FPM/FrankenPHP
io-read	1.144	3.262	4.066	Swoole
io-write	268	513	230	FrankenPHP

Latência p99 (ms — menor é melhor)

Endpoint	FPM+JIT	FrankenPHP	Swoole
cpu-bound	3.467	3.334	9.205
io-read	205	210	92
io-write	506	364	1.182

Speedup vs FPM

Endpoint	FrankenPHP	Swoole
cpu-bound	1,00×	0,73×
io-read	2,85×	3,55×
io-write	1,91×	0,86×

O que os números dizem

1. CPU puro → é o JIT, e ele empata. FPM e FrankenPHP têm o mesmo JIT (opcache.jit=1255, buffer 128M) e deram exatamente o mesmo número (19,7 req/s). Faz sentido: a economia de boot do worker não ajuda quando o tempo é gasto computando, não inicializando. O Swoole ficou atrás por overhead do seu reactor no caminho síncrono.

2. Leitura → runtimes persistentes voam. Swoole 3,55× e FrankenPHP 2,85× o FPM. Aqui o que domina é o reúso do container de injeção de dependência do Symfony e o zero bootstrap por request — o FPM paga esse pedágio em toda requisição. Swoole ainda leva o melhor p99 (92ms).

3. Escrita → FrankenPHP brilha, Swoole sofre. FrankenPHP fez 1,9× o FPM e teve o melhor p99. Já o Swoole degradou (p99 de 1.182ms) — é o sintoma clássico de contenção nas conexões persistentes com poucos workers no caminho de escrita. Foi exatamente o que o teste de io-write foi desenhado pra expor: no FPM a conexão abre/fecha por request; no Swoole/FrankenPHP ela persiste por worker e precisa ser gerenciada.

Tropeços de setup que valem registrar

Montar isso em PHP 8.4 + Docker novo (2026) rendeu alguns perrengues que podem te poupar tempo:

Composer bloqueando por advisory. O Composer atual recusa versões com security advisory na resolução. Vários advisories recentes do Symfony cobrem toda a linha 7.x — desliguei com config.policy.advisories.block=false (PoC local).
Extensão zip faltando. Sem zip/unzip, o composer install falha ao extrair os pacotes. Adicionei zip via install-php-extensions nas três imagens.
symfony/var-exporter 8.x vs Doctrine ORM 3. O ORM precisa do LazyGhost da var-exporter 6.4/7; a 8.x removeu o trait. Fixei em 7.2.*.
Controller sem controller.service_arguments. Controller "plano" (sem AbstractController) não recebe injeção em argumentos de action — precisei taggear no services.yaml.
Traefik + Docker socket. O daemon novo exige API ≥ 1.40 e o provider Docker do Traefik v3.2 negocia 1.24 → quebra. Troquei para o file provider (config estática), roteando por nome de container. Mais robusto e sem depender do socket.

Como reproduzir

# subir o ambiente
docker compose up -d --build

# rodar a matriz (Python + aiohttp) e salvar CSV/JSON
./.venv/bin/python bench/loadtest.py -d 12 -c 64 -w 4

# gerar os gráficos comparativos a partir do resultado
./.venv/bin/python bench/plot_results.py

Código completo (Dockerfiles, configs, gerador de carga e notebook) no GitHub: jeferson-guedes/bench-php-vanilla-vs-modern

Veredito

Não existe "runtime mais rápido". Existe runtime certo para a carga:

App I/O-bound de leitura (APIs, dashboards): Swoole ou FrankenPHP — ganho real de 3×.
Escrita concorrente: FrankenPHP, com atenção ao pooling; Swoole exige tunar workers × conexões.
CPU-bound: ligue o JIT e durma tranquilo — FPM clássico segura o tranco igual.

O ganho dos runtimes modernos é arquitetural (estado persistente, sem bootstrap), não mágico. Onde não há bootstrap a economizar, o bom e velho FPM com JIT continua competitivo — e muito mais simples de operar.

Ambiente: PHP 8.4, Symfony 7.2, Doctrine ORM 3, MySQL 8, Docker 29.4 no macOS. Carga: 64 conexões, 12s/medição, 4 workers por runtime. Números são de uma única rodada local — para conclusões de produção, rode várias vezes e descarte a primeira.

▎ 💬 Achou um furo na metodologia? Tem caso, config ou runtime que ficou de fora? Comenta aí — quero transformar isto num guia definitivo sobre a melhor abordagem em PHP, e quanto mais gente questionar os números.

PHP Modificando propriedade privada sem modificadores

Jeferson Guedes — Thu, 19 Jan 2023 23:31:21 +0000

Apresentação

Fala pessoal tudo bem !? A ideia deste artigo é ajudar vocês a contribuir mais com testes dentro da empresa

Vamos a seguinte hipótese imagina que te peçam para testar uma classe inchada cheio de classes e um alto acoplamento e claro essa classe não tem as propriedade sendo recebidas por construtor o que vocês

Classe exemplo:

<?php

use ...
class SomeClass
{
    private AnotherClass $anotherClass;

    public function __construct()
    {
        $this->anotherClass = new AnotherClass();
        //... another calls classes

    }

    public function someMethod(Type $args): SomeType
    {
        //... any business logic 
        $this->anotherClass->doIt();

        return $someType;
    }
}

Pensam comigo terá um alto acoplamento e se for aceitar que essa classe seja enviada por parâmetro no seu construtor possa ser que quebre compatibilidade com outras classes que podem estar usando.

Imagina que anotherClass::doIt seja algo arriscado que se for chamado possa ter uma consequência grave por exemplo um update em massa para resolver esse problema você pode sobreescrever essa propriedade no seu test:


<?php

class SomeTest extends TestCase
{
    public function testAnywere(): void
    {
        $anotherClassMock = $this->getMockBuilder(AnotherClass::class)
            ->disableOriginalConstructor()
            ->getMock();
        $anotherClassMock
            ->method('doIt');

        $someClass = new SomeClass();
        $setSomeClassClosure = function ()  use ($anotherClassMock){
            $this->anotherClass = $anotherClassMock;
        };
        $doSetSomeClassClosure = $setSomeClassClosure
            ->bindTo($someClass, SomeClass::class);
        $doSetSomeClassClosure();

    }
}

Obs: A ideia desta forma de testar é te dar poder para conseguir resolver algo legado e bastante arriscado, no geral o ideal seria uma reescrita deste método

Crie um servidor PHP + API Rest + GraphQL

Jeferson Guedes — Tue, 28 Jun 2022 19:36:50 +0000

Contextualização:

Vamos construir um servidor GraphQL + RestFull escrito em ApiPlatform, este projeto irá te ajudar a entender um sobre a facilidade de construir uma API Rest e GraphQL no mesmo projeto.

Para este tutorial eu desenvolvi uma lista de itens a serem pagos para um planejamento de casamento.

A ideia deste projeto é bem simples casal tem 0::N eventos cada evento tem um nome e valor.

Bom, chega de conversa e vamos para o código:

Pré requisitos:

Docker + Docker Compose
PHP 8.1
Composer

Instalação:

Abra um terminal e crie um diretório onde você deseja que seu código fique em seu computador.

$ cd ~/
$ mkdir wedding
$ cd wedding

Com isso seu projeto Symfony será criado, execute passo a passo.

$ composer create-project symfony/skeleton:"6.1.*" .
$ composer req orm # y para criar o docker-compose.yml
$ composer req api
$ composer require webonyx/graphql-php

Suba seu container com banco de dados configurado

$ docker-compose up -d

Agora vamos criar nossas entidades, mas antes precisamos criar uma dependência de desenvolvimento

$ composer require --dev symfony/maker-bundle

Entidade Couple, em seu terminal digite:

$ php bin/console make:entity Couple
manName: <string:255> not null
womanName: <string:255> not null

Siga com os nomes como no print:

Entidade Event, em seu terminal digite:

$ php bin/console make:entity Event
name: <string:255> not null
price: <float> not null

Vamos voltar para a criação de entidade, mas vamos só criar uma relação 0::N de Couple com Events

$ php bin/console make:entity Couple

No mapeamento da classe Event você precisará ajustar na mão o relacionamento, deve ficar assim:


#src/Entity/Event.php
class Event
{
    ...
    #[ORM\ManyToOne(targetEntity: Couple::class)]
    #[ORM\JoinColumn(name: "couple_id", referencedColumnName: "id", nullable: true)]
    private $couple;
    ...
}

Vamos gerar nossa migrações, no seu e subir a estrutura de SQL.

$ php bin/console make:migration
$ php bin/console doctrine:migration:migrate

Pressione yes para apagar todos os dados do banco de app

Configuração

Vamos partir de agora mexer somente nas entidades.

1.) Importar Attribute ApiResource em sua classe src/Entity/Event.php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use App\Repository\EventRepository;
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity(repositoryClass: EventRepository::class)]
#[ApiResource]
class Event
{
        ...
        #[ORM\ManyToOne(targetEntity: Couple::class)]
    #[ORM\JoinColumn(name: "couple_id", referencedColumnName: "id", nullable: true)]
    #[ApiSubresource]
    private $couple;
        ...

2.) Importar Attribute ApiResource em sua classe src/Entity/Couple.php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use App\Repository\CoupleRepository;
use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity(repositoryClass: CoupleRepository::class)]
#[ApiResource]
class Couple
...

Execute:

Rode seu servidor local php para ter acesso ao localhost

Acesse: http://localhost:7777/api - Swagger documentation RESTAPI

Acesse: http://localhost:7777/api/graphql - Playground GraphQL

Veja algumas queries que você pode fazer em GraphQL:

Para criar um novo casal faça isso:

mutation CretateCouple($couple: createCoupleInput! ) {
  createCouple(input: $couple) {
    couple {
      manName
      womanName
    }
  }
}
#query variables
{
  "couple":{
    "manName": "joe",
    "womanName": "mary"
  }
}

Para buscar todos:

query {
  couples {
    edges {
      node {
        manName
        womanName
      }
    }
  }
}

Conclusão

Espero que tenham gostado fiz um exemplo bem simples para ajudar a entender mais sobre essas ferramentas tão maravilhosas que nem sempre temos contato.

Referências:

Symfony
ApiPlatform
Symfony Maker