Symfony 8 a PHP 8.4-en: FrankenPHP vs RoadRunner Benchmarked

A Symfony 7.4 LTS kiadása kulcsfontosságú pillanatot jelent a PHP ökoszisztémában. Míg maga a keretrendszer robusztus funkciókat vezet be, mint például a szigorúbb típusbiztonság és a natív PHP serializáció a konténerek számára, az igazi forradalom történik abban, hogyan szolgáljuk ezeket az alkalmazásokat. A Go-ban írt alkalmazásszerverek éretté váltak, olyan „Worker Mode” funkciókat kínálva, amelyek egyszer indítják el a kernelt, és megtartják a memóriában, csökkentve a késleltetést és felgyorsítva az átviteli sebességet. NGINX + PHP-FPM Ebben a cikkben a két nehéz súlyt egymás ellen állítjuk: (a modern kihívó épült Caddy) és Mindkettőt egy PHP 8.4-en futó Symfony 8 alkalmazásban fogjuk végrehajtani, összehasonlítjuk architektúráikat és elemezzük teljesítményüket. FrankenPHP RoadRunner A versenyzők franciaországi A Caddy webkiszolgáló tetején épült, Ez összeállítja a PHP-t közvetlenül a bináris (vagy használ egy konkrét build) és kihasználja Caddy automatikus és A támogatás. FrankenPHP HTTPS HTTP/3 Ez összeomlik NGINX, PHP-FPM és az SSL terminátor egyetlen bináris. Key Advantage: Native támogatás a Runtime komponensen keresztül a Symfony 7.4+ segítségével. úttörő A Spiral Scout által kifejlesztett RoadRunner egy nagy teljesítményű PHP alkalmazásszerver, terhelési kiegyenlítő és folyamatkezelő. Rugalmas és ökoszisztéma. gazdag plugin rendszert kínál ( az , az , A szimfóniával mélyen összekapcsolódik. Key Advantage: gRPC Queues KV storage Kiváló integráció a runtime/roadrunner-symfony-nyholm segítségével. A benchmark kód (Symfony 8 és PHP 8.4) Ahhoz, hogy az összehasonlítás méltányos legyen, könnyű API-végpontokat hozunk létre, amelyek kölcsönhatásba lépnek egy adatbázissal. Ez nemcsak a nyers „Hello World” sebességet vizsgálja, hanem az adatbázis-kapcsolatok és a szerializáció felülvizsgálatát egy tartós munkavállalói környezetben. PHP 8.4 Property Hooks (ha rendelkezésre áll a buildben) vagy szabványos beírt tulajdonságokat használunk. A széles körű kompatibilitás érdekében ebben az útmutatóban a szabványos 8.3+ promóciós tulajdonságokat Attribútumokkal használjuk. The Entity: namespace App\Entity; use Doctrine\ORM\Mapping as ORM; use Symfony\Component\Serializer\Attribute\Groups; #[ORM\Entity] #[ORM\Table(name: 'products')] class Product { #[ORM\Id] #[ORM\GeneratedValue] #[ORM\Column] #[Groups(['product:read'])] private ?int $id = null; public function __construct( #[ORM\Column(length: 255)] #[Groups(['product:read'])] public string $name, #[ORM\Column] #[Groups(['product:read'])] public int $price, ) {} public function getId(): ?int { return $this->id; } } Mi használjuk a A Symfony legújabb verzióiban bevezetett attribútum automatikusan feltérképezi a JSON-bevitelt. The Controller: #[MapRequestPayload] namespace App\Controller; use App\DTO\ProductDto; use App\Entity\Product; use Doctrine\ORM\EntityManagerInterface; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\HttpKernel\Attribute\MapRequestPayload; use Symfony\Component\Routing\Attribute\Route; #[Route('/api/v1')] class BenchmarkController extends AbstractController { #[Route('/products', methods: ['POST'])] public function create( #[MapRequestPayload] ProductDto $dto, EntityManagerInterface $em ): JsonResponse { // Simple logic to test throughput $product = new Product($dto->name, $dto->price); $em->persist($product); $em->flush(); return $this->json($product, 201, [], ['groups' => 'product:read']); } #[Route('/ping', methods: ['GET'])] public function ping(): JsonResponse { $this->counter->increment(); // Increment on each call return new JsonResponse([ 'status' => 'pong', 'timestamp' => time() ]); } } The DTO: namespace App\DTO; use Symfony\Component\Validator\Constraints as Assert; class ProductDto { public function __construct( #[Assert\NotBlank] #[Assert\Length(min: 3)] public string $name, #[Assert\Positive] public int $price, ) {} } Benchmark eredmények A wrk-t (egy modern HTTP-benchmarking eszközt) ugyanazon a helyi hálózaton lévő külön gépeken futtattuk, hogy elkerüljük a CPU-konfliktusokat. Methodology: 8 magos CPU, 16 GB RAM Machine: 30 másodperc, 100 versenyző kapcsolat. Test: /api/v1/ping (Raw átviteli sebesség) és /api/v1/products (adatbázis interakció) Target: NGINX és PHP FPM (8.4) Baseline: A forgatókönyv: The “Ping” (Raw Overhead) +---------------------+----------------+---------------+---------------------+ | Server | Req/Sec | Latency (Avg) | Memory Usage | +---------------------+----------------+---------------+---------------------+ | PHP-FPM | ~2,100 | 45ms | Low (per process) | | FrankenPHP (Worker) | ~8,500 | 4ms | Moderate | | RoadRunner | ~9,200 | 3ms | Low | +---------------------+----------------+---------------+---------------------+ Mindkét alkalmazás kiszolgálója decimálja a PHP-FPM-t. A RoadRunner a rendkívül optimalizált Go-alapú RPC-kommunikáció miatt enyhe előnyt jelent az egyszerű JSON-válaszok nyers átviteli sebességében. B forgatókönyv: Adatbázis írása (valódi világ) +-------------+---------------+----------------+------------+ | Server | Req/Sec | Latency (Avg) | Stability | +-------------+---------------+----------------+------------+ | PHP-FPM | ~850 | 110ms | Stable | | FrankenPHP | ~3,200 | 25ms | Excellent | | RoadRunner | ~3,400 | 22ms | Excellent | +-------------+---------------+----------------+------------+ A szakadék szűkül, amikor az adatbázis a palackozási pont. Az állandó alkalmazásindítás (Worker Mode) azonban azt jelenti, hogy a Symfony nem kezdi újra a tartályt, a Doktrína metaadatokat vagy az eseményhallgatókat minden egyes kéréshez. és 3x-4x teljesítménynövekedés a standard FPM-hez képest. FrankenPHP RoadRunner C forgatókönyv: The “Number Cruncher” (CPU Bound) Ez a teszt a nyers végrehajtási sebességet és a munkafolyamat stabilitását méri, amikor a CPU 100% -ban van rögzítve.Meg fogjuk végezni a mátrixszorzást (N x N), egy klasszikus O(n3) algoritmust, amely arra kényszeríti a PHP-motort, hogy keményen dolgozzon anélkül, hogy I/O várakozási időre támaszkodna. The Code (Matrix Service): namespace App\Service; class MathService { public function multiplyMatrix(int $size): array { $matrixA = $this->generateMatrix($size); $matrixB = $this->generateMatrix($size); $result = array_fill(0, $size, array_fill(0, $size, 0)); for ($i = 0; $i < $size; $i++) { for ($j = 0; $j < $size; $j++) { for ($k = 0; $k < $size; $k++) { $result[$i][$j] += $matrixA[$i][$k] * $matrixB[$k][$j]; } } } return $result; } private function generateMatrix(int $size): array { $matrix = []; for ($i = 0; $i < $size; $i++) { for ($j = 0; $j < $size; $j++) { $matrix[$i][$j] = rand(1, 100); } } return $matrix; } } The Controller: namespace App\Controller; use App\Service\MathService; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\Routing\Attribute\Route; #[Route('/api/v1')] class MathController extends AbstractController { #[Route('/math/matrix/{size}', requirements: ['size' => '\d+'], methods: ['GET'])] public function matrix(int $size, MathService $service): JsonResponse { // $size = 100 creates 1,000,000 iterations. $start = microtime(true); $service->multiplyMatrix($size); $duration = microtime(true) - $start; return $this->json([ 'size' => $size, 'duration_ms' => $duration * 1000, 'memory_peak' => memory_get_peak_usage(true) ]); } } Results (Matrix Size: 150x150, 50 Concurrent Users): +--------------+---------------------+----------------+----------------------+ | Server | Avg Response Time | Std. Deviation | Throughput (Req/Sec) | +--------------+---------------------+----------------+----------------------+ | PHP-FPM | 210ms | 15ms | ~450 | +--------------+---------------------+----------------+----------------------+ | FrankenPHP | 205ms | 45ms | ~465 | +--------------+---------------------+----------------+----------------------+ | RoadRunner | 208ms | 8ms | ~460 | +--------------+---------------------+----------------+----------------------+ Mindhárom gyakorlatilag azonos módon működik. Ez azért várható, mert itt a Zend Engine (a PHP maga), nem pedig a webszerver. A RoadRunner jelentősen alacsonyabb standard eltérést mutatott (jitter). A folyamatszigetelése (csövekkel összekapcsolt külön munkatárs binárisok révén) úgy tűnik, hogy valamivel kiszámíthatóbb módon kezeli a CPU-koncentrációt, mint a FrankenPHP szálas modellje nehéz terhelés alatt, ahol a Go rutinok és a C-szálak ugyanazon CPU-időszakokért versenyeznek. D forgatókönyv: A „Big Data Stream” (I/O és Memory Bound) Ez a „munkásgyilkos”. Hosszú távú munkakörnyezetben egy nagy fájl memóriába való pufferezése végzetes. tesztelnünk kell a streaming képességeket. 100 000 soros CSV jelentést fogunk generálni a repülőn, és továbbítjuk az ügyfélnek. The Code (Streaming Response): namespace App\Controller; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\HttpFoundation\StreamedResponse; use Symfony\Component\Routing\Attribute\Route; #[Route('/api/v1')] class ReportController extends AbstractController { #[Route('/report/stream', methods: ['GET'])] public function streamBigReport(): StreamedResponse { $response = new StreamedResponse(function () { $handle = fopen('php://output', 'w+'); fputcsv($handle, ['ID', 'Name', 'Email', 'Status', 'Created_At']); // Simulate 100k rows for ($i = 0; $i < 100_000; $i++) { fputcsv($handle, [ $i, "User $i", "user$i@example.com", $i % 2 === 0 ? 'Active' : 'Inactive', date('Y-m-d H:i:s') ]); // Crucial: Flush buffer to prevent memory explosion if ($i % 1000 === 0) { flush(); } } fclose($handle); }); $response->headers->set('Content-Type', 'text/csv'); $response->headers->set('Content-Disposition', 'attachment; filename="big_report.csv"_report.csv"'); // RoadRunner/FrankenPHP specific header to disable internal buffering if needed $response->headers->set('X-Accel-Buffering', 'no'); return $response; } } Results (Downloading 50MB CSVs): +------------+---------------------------+---------------------------+--------------+ | Server | Time to First Byte (TTFB) | Max Memory Usage (Worker) | Success Rate | +------------+---------------------------+---------------------------+--------------+ | PHP-FPM | 30ms | 4MB | 100% | | FrankenPHP | 5ms | 6MB | 100% | | RoadRunner | 12ms | 4MB | 100% | +------------+---------------------------+---------------------------+--------------+ FrankenPHP: megnyeri a TTFB-t (Time To First Byte). Mivel a FrankenPHP közvetlenül beágyazza a PHP-t, az echo/fwrite kimenet szinte azonnal a Caddy által kezelt hálózati aljzatba kerül. RoadRunner: Szigorúan betartja a streaming szerződéseket. Az adatok a PHP Worker -> Relay (Pipes/Socket) -> RoadRunner (Go) -> Client. Bár rendkívül gyors, van egy apró elméleti felületen összehasonlítva a FrankenPHP megosztott memória megközelítés. Memória: Mindkét kiszolgáló sikeresen megtartotta a memóriát (~4–6 MB), mert a StreamedResponse-t használtuk. Ha ezt a szálat egy változóba buffereltük volna, mindkét munkavállaló összeomlott volna vagy megállt volna a Garbage Collection számára, ami megöli az átviteli kapacitást. E forgatókönyv: A „Pixel Cruncher” (képfeldolgozás) Töltsön fel egy 4K képet (3840x2160), változtassa meg a méretét 800x600-ra, alkalmazzon szürke méretű szűrőt, és adja vissza a bináris adatokat. Szükségünk van a A könyvtár, a standard absztrakció A PHP. imagine/imagine GD/Imagick The Code (Image Service): namespace App\Service; use Imagine\Gd\Imagine; use Imagine\Image\Box; class ImageProcessor { private Imagine $imagine; public function __construct() { // We use the GD driver as it is strictly CPU-bound and blocking $this->imagine = new Imagine(); } public function process(string $imagePath): string { $image = $this->imagine->open($imagePath); // Resize and apply effects (CPU Intensive) $image->resize(new Box(800, 600)); $image->effects()->grayscale(); // Return binary string (Memory Intensive) return $image->get('jpeg', ['quality' => 80]); } } The Controller: namespace App\Controller; use App\Service\ImageProcessor; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\HttpFoundation\File\UploadedFile; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\Routing\Attribute\Route; #[Route('/api/v1')] class MediaController extends AbstractController { #[Route('/media/process', methods: ['POST'])] public function process(Request $request, ImageProcessor $processor): Response { /** @var UploadedFile $file */ $file = $request->files->get('image'); if (!$file) { return new Response('No image provided', 400); } $processedImage = $processor->process($file->getPathname()); return new Response($processedImage, 200, [ 'Content-Type' => 'image/jpeg', // Prevent caching for benchmark accuracy 'Cache-Control' => 'no-cache, no-store, must-revalidate', ]); } } Benchmark Configuration: Bemenet: 5 MB JPEG (High-Res 4K) Verseny: 20 egyidejű felhasználó (a feltöltések kitörését szimulálja). Időtartam: 60 másodperc Worker Pool Limit: Mindkét szerver 8 munkavállalóra korlátozódik az erőforrás-korlátozás szimulálása érdekében. +-------------+-------------------+-------------------------+----------------------+----------+ | Server | Avg Response Time | 99th Percentile Latency | Throughput (Req/Sec) | Failures | +-------------+-------------------+-------------------------+----------------------+----------+ | PHP-FPM | 450ms | 1.2s | ~42 | 0 | | FrankenPHP | 430ms | 950ms | ~48 | 0 | | RoadRunner | 435ms | 880ms | ~47 | 0 | +-------------+-------------------+-------------------------+----------------------+----------+ Függetlenül attól, hogy az FPM-t, a RoadRunner-t vagy a FrankenPHP-t használja-e, egy CPU-mag 100%-ban ~400 ms kérésre van elfoglalva. Concurrency Management (The Real Difference): PHP-FPM: A feldolgozás addig tart, amíg el nem éri a pm.max_children értéket. Ha elérjük a határértéket, az NGINX puffer feltöltődik, ami végül 502 hibaüzenetet eredményez, ha elérjük az időzítést. RoadRunner: A munkavállalók rögzített csoportja van. Ha 8 kérés feldolgozásra kerül, a 9. kérés a RoadRunner belső prioritási sorában várakozik (Go-ban írva). Ez a sor rendkívül hatékony. Megakadályozza, hogy a szerver összeomoljon az OOM-ban (Out Of Memory), de bevezeti a "Wait Time" -t a felhasználó számára. FrankenPHP: Hasonló a RoadRunner-hez, de használja a Caddy csatlakozási kezelését. A robbanást enyhén gyorsabban kezelte a nyers átviteli sebességben, valószínűleg a fájlleíró átadásának alacsonyabb túlfeszültsége miatt a RoadRunner RPC csöveihez képest. F forgatókönyv: A „súlyos keret” indítási teszt (Serialization) A „Worker Mode” módban a kernel egyszer elindul. Azonban a futtatási időnek még mindig meg kell oldania a kérés-specifikus tisztításokat és a nehéz objektum-szerializációt. Ez a teszt a komplex objektum-diagramok szerializálásának túlnyomó mértékét méri – ami gyakori a Symfony alkalmazásokban az API Platform vagy a kiterjedt Doktrína gyűjtemények használatával. 50 Rendelési entitás gyűjteményét sorosítjuk, amelyek mindegyike és Ez hangsúlyozza a serializer és a memória menedzser. OrderItems Product The Code: namespace App\Entity; use App\Repository\OrderRepository; use Doctrine\Common\Collections\ArrayCollection; use Doctrine\Common\Collections\Collection; use Doctrine\ORM\Mapping as ORM; use Symfony\Component\Serializer\Attribute\Groups; #[ORM\Entity(repositoryClass: OrderRepository::class)] #[ORM\Table(name: 'orders')] class Order { #[ORM\Id, ORM\GeneratedValue, ORM\Column] #[Groups(['order:read'])] private ?int $id = null; #[ORM\OneToMany(targetEntity: OrderItem::class, mappedBy: 'orderRef', cascade: ['persist', 'remove'])] #[Groups(['order:read'])] public Collection $items; public function __construct() { $this->items = new ArrayCollection(); } public function getId(): ?int { return $this->id; } public function getItems(): Collection { return $this->items; } public function addItem(OrderItem $item): self { if (!$this->items->contains($item)) { $this->items[] = $item; $item->orderRef = $this; } return $this; } } The Controller: namespace App\Controller; use App\Repository\OrderRepository; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\Routing\Attribute\Route; #[Route('/api/v1')] class HeavyController extends AbstractController { #[Route('/heavy/orders', methods: ['GET'])] public function list(OrderRepository $repo): JsonResponse { // Assume database is seeded with 50 complex orders $orders = $repo->findAll(); return $this->json($orders, 200, [], ['groups' => 'order:read']); } } Results (100 Concurrent Users): +----------------------+--------------------+----------------------+----------------+ | Metric | NGINX + FPM | FrankenPHP (Worker) | RoadRunner | +----------------------+--------------------+----------------------+----------------+ | Throughput (req/sec) | ~180 | ~420 | ~405 | | Memory per Worker | Low (Reset/req) | High (Accumulates) | Stable | | GC Overhead | Negligible | Moderate | Low | +----------------------+--------------------+----------------------+----------------+ Hatalmas ugrást mutat az FPM-nél (2.3x), mert a Doctrine Metadata és a Serializer ClassMetadata már a memóriában van. Ez a RoadRunner-t kissé kiemeli, mivel a „CGO” (C-Go) nem létezik; a FrankenPHP közvetlenül a beágyazott PHP-motorra adja át a mutatót. FrankenPHP: : Rendkívül stabil. Bár kissé lassabb, mint a FrankenPHP itt, a memória lábnyoma laposabb volt. A bomlás azt sugallja, hogy a nagy JSON haszonterhelések átadása az RPC csöveken (Standard Streams/TCP) kis szerializációs büntetést szenved, amelyet a FrankenPHP elkerül. RoadRunner G forgatókönyv: A „Keep-Alive” és a memória szivárgás stresszteszt Hosszú ideig futó PHP szkriptek szivárog a memória. Ez az élet ténye. Mindkét szerveren mechanizmusok vannak a munkavállalók megölésére és helyettesítésére (TTL/Max Requests). Teszteljük, hogy mennyire „szép” ez az újrahasznosítás. The “Leaky” Code: namespace App\Controller; use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\Routing\Attribute\Route; class LeakController { // Intentional static leak private static array $buffer = []; #[Route('/api/v1/leak', methods: ['GET'])] public function leak(): JsonResponse { // Leak 1MB per request self::$buffer[] = str_repeat('A', 1024 * 1024); return new JsonResponse(['memory' => memory_get_usage(true)]); } } Configuration (Restart every 50 requests): Munkahelyek száma: max_jobs: 50 FrankenPHP: FRANKENPHP_CONFIG=”munkavállaló ./public/index.php 16 50" Results (Sustained Load): +------------------------+-------------+--------------+ | Metric | RoadRunner | FrankenPHP | +------------------------+-------------+--------------+ | Restart Latency Spike | ~15ms | ~40ms | | Memory Reclamation | Instant | Instant | | Consistency | Smooth | Slight Jitter| +------------------------+-------------+--------------+ RoadRunner: A spirál/roadrunner folyamatmenedzser hihetetlenül érett. „puha visszaállításokat” végez – egy új dolgozót forgat fel, mielőtt megöli a régit (átfedő). Ez szinte észrevehetetlen késleltetési csúcsokat eredményez a felhasználó számára. FrankenPHP: Jól kezeli az újraindításokat is, de kissé magasabb „jittert” (varianciát) figyeltünk meg, amikor több szál úgy döntött, hogy egyszerre újraindítja. következtetés A FrankenPHP és a RoadRunner közötti csata a Symfony 8 ökoszisztémájában nem a „gyors vs. lassú” kérdésről szól – mindkettő hihetetlenül gyors. A FrankenPHP ügyében A legjobb: Modern „felhőalapú” alkalmazások, az egyszerűséget igénylő fejlesztők és a HTTP/3 / Early Hints-t igénylő projektek. Killer funkció: Az egyetlen bináris. Képes elküldeni egy Docker képet, amely tartalmazza a Web Server (Caddy) és az App Server (PHP) egy telepítési álom. Teljesítmény: A beágyazott architektúra miatt kissé magasabb nyers átviteli teljesítmény a kis terheléseken. A „Modern Standard.” valószínűleg az alapértelmezett Symfony Docker beállítások. A RoadRunner ügyében Legjobb: vállalati mikroszolgáltatások, magas forgalomú rendszerek, amelyek szigorú SLA-kat és nehéz háttérfeldolgozást igényelnek. Ha szüksége van egy gRPC szerverre, egy Kafka fogyasztóra, egy elosztott Key-Value áruházra és egy Metrics exportőrre egy binárisban, akkor a RoadRunner páratlan. Stabilitás: A folyamatmenedzser harci keménységű. Ha banki API-t vagy nagyteljesítményű sorrendet épít, válassza a RoadRunner-t. Kezdjük a Csökkenti a belépési akadályt a nagy teljesítményű PHP-hez. ha speciális fejlett funkciókra (RPC/Queues) van szüksége, vagy ha a Caddy konfigurációjában előfordulnak szélessávú esetek. FrankenPHP RoadRunner A teljes megvalósítás és a projekt előrehaladása megtalálható a GitHub-on: [ ] Source Code: https://github.com/mattleads/FrankenVSRoadRunner https://github.com/mattleads/FrankenVSRoadRunner Let’s Connect! Ha ezt hasznosnak találod, vagy kérdésed van a megvalósítással kapcsolatban, szeretném hallani tőled. Maradjunk kapcsolatban, és tartsuk a beszélgetést ezeken a platformokon: Linkedin: [https://www.linkedin.com/in/matthew-mochalkin/] Székesfehérvár (Twitter): [https://x.com/MattLeads] Telegrám: [https://t.me/MattLeads] GitHub: [https://github.com/mattleads] https://www.linkedin.com/in/matthew-mochalkin/ https://x.com/MattLeads https://t.me/MattLeads https://github.com/mattleads