The release of Symfony 7.4 LTS marks a pivotal moment in the PHP ecosystem. While the framework itself introduces robust features like stricter type safety and native PHP serialization for containers, the real revolution is happening in how we serve these applications.Gone are the days when NGINX + PHP-FPM was the undisputed default. Application servers written in Go have matured, offering “Worker Mode” capabilities that boot your kernel once and keep it in memory, slashing latency and skyrocketing throughput.
In this article, we pit the two heavyweights against each other: FrankenPHP (the modern challenger built on Caddy) and RoadRunner (the battle-tested veteran from Spiral Scout). We will implement both in a Symfony 8 application running on PHP 8.4, compare their architectures and analyze their performance.
The Contenders
FrankenPHP
Built on top of the Caddy web server, FrankenPHP is a modern application server that simplifies the stack. It compiles PHP directly into the binary (or uses a specific build) and leverages Caddy’s automatic HTTPS and HTTP/3 support.
Key Advantage: Simplicity. It collapses NGINX, PHP-FPM and the SSL terminator into a single binary.
Native support via the Runtime component with Symfony 7.4+.
RoadRunner
Developed by Spiral Scout, RoadRunner is a high-performance PHP application server, load balancer and process manager. It uses a pool of workers to handle requests.
Key Advantage: Robustness and Ecosystem. It offers a rich plugin system (gRPC, Queues, KV storage) that integrates deeply with Symfony.
Excellent integration via the runtime/roadrunner-symfony-nyholm.
The Benchmark Code (Symfony 8 & PHP 8.4)
To make the comparison fair, we will create a lightweight API endpoints that interacts with a database. This tests not just raw “Hello World” speed, but the overhead of database connections and serialization in a persistent worker environment.
The Entity: We use PHP 8.4 Property Hooks (if available in your build) or standard typed properties. For broad compatibility in this guide, we use standard 8.3+ promoted properties with Attributes.
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;
}
}
The Controller: We use the #[MapRequestPayload] attribute introduced in recent Symfony versions to map JSON input automatically.
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 Results
Methodology: We used wrk (a modern HTTP benchmarking tool) running on a separate machine in the same local network to avoid CPU contention.
Machine: 8-Core CPU, 16GB RAM.
Test: 30 seconds, 100 concurrent connections.
Target: /api/v1/ping (Raw throughput) and /api/v1/products (Database interaction).
Baseline: NGINX + PHP-FPM (8.4).
Scenario A: 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 |
+---------------------+----------------+---------------+---------------------+
Both application servers decimate PHP-FPM. RoadRunner holds a slight edge in raw throughput for simple JSON responses due to its highly optimized Go-based RPC communication.
Scenario B: Database Write (Real World)
+-------------+---------------+----------------+------------+
| Server | Req/Sec | Latency (Avg) | Stability |
+-------------+---------------+----------------+------------+
| PHP-FPM | ~850 | 110ms | Stable |
| FrankenPHP | ~3,200 | 25ms | Excellent |
| RoadRunner | ~3,400 | 22ms | Excellent |
+-------------+---------------+----------------+------------+
The gap narrows when the database becomes the bottleneck. However, the persistent application boot (Worker Mode) means Symfony doesn’t re-initialize the container, Doctrine metadata, or event listeners for every request. Both FrankenPHP and RoadRunner offer a 3x-4x performance boost over standard FPM.
Scenario C: The “Number Cruncher” (CPU Bound)
This test measures raw execution speed and the stability of the worker process when the CPU is pinned at 100%. We will perform a matrix multiplication (N x N), a classic O(n³) algorithm that forces the PHP engine to work hard without relying on I/O wait times.
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 |
+--------------+---------------------+----------------+----------------------+
All three perform nearly identically. This is expected because the bottleneck here is the Zend Engine (PHP itself), not the web server. No amount of Go wrapping can make PHP’s for loops faster.
RoadRunner showed significantly lower standard deviation (jitter). Its process isolation (via separate worker binaries connected by pipes) seems to handle CPU contention slightly more predictably than FrankenPHP’s threaded model under heavy load, where Go routines and C threads compete for the same CPU time slices.
Scenario D: The “Big Data Stream” (I/O & Memory Bound)
This is the “Worker Killer.” In a long-running worker environment, buffering a large file into memory is fatal. We must test streaming capabilities. We will generate a 100,000-row CSV report on the fly and stream it to the client.
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",
"[email protected]",
$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: Wins on TTFB (Time To First Byte). Because FrankenPHP embeds PHP directly, the echo/fwrite output goes almost instantly to the network socket managed by Caddy. It feels remarkably snappy.
- RoadRunner: Requires strictly adhering to streaming contracts. The data travels from PHP Worker -> Relay (Pipes/Socket) -> RoadRunner (Go) -> Client. While extremely fast, there is a tiny theoretical overhead compared to FrankenPHP’s shared-memory approach.
- Memory: Both servers successfully kept memory flat (~4–6MB) because we used StreamedResponse. If we had buffered this string in a variable, both workers would have crashed or paused for Garbage Collection, killing throughput.
Scenario E: The “Pixel Cruncher” (Image Processing)
Upload a 4K image (3840x2160), resize it to 800x600, apply a grayscale filter and return the binary data. This forces the CPU to work hard and the memory to spike as the uncompressed bitmap is loaded.
We need the imagine/imagine library, a standard abstraction for GD/Imagick in PHP.
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:
- Input: 5MB JPEG (High-Res 4K).
- Concurrency: 20 concurrent users (simulating a burst of uploads).
- Duration: 60 seconds.
- Worker Pool Limit: Both servers limited to 8 workers to simulate resource constraint.
+-------------+-------------------+-------------------------+----------------------+----------+
| 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 |
+-------------+-------------------+-------------------------+----------------------+----------+
Image processing is synchronous. Whether you use FPM, RoadRunner, or FrankenPHP, one CPU core is 100% occupied for ~400ms per request. The “Magic” of Go cannot fix PHP’s single-threaded nature here.
Concurrency Management (The Real Difference):
- PHP-FPM: Spawns processes until pm.max_children is reached. If the limit is hit, the NGINX buffer fills up, eventually leading to 502 errors if the timeout is reached.
- RoadRunner: Has a fixed pool of workers. If 8 requests are processing, the 9th request waits in RoadRunner’s internal priority queue (written in Go). This queue is highly efficient. It prevents the server from crashing OOM (Out Of Memory) but introduces “Wait Time” for the user.
- FrankenPHP: Similar to RoadRunner, but uses Caddy’s connection handling. It handled the burst slightly faster in raw throughput, likely due to lower overhead in passing the file descriptor compared to RoadRunner’s RPC pipes.
Scenario F: The “Heavy Framework” Boot Test (Serialization)
In “Worker Mode” the kernel boots once. However, the runtime still needs to handle request-specific cleanups and heavy object serialization. This test measures the overhead of serializing complex object graphs — a common bottleneck in Symfony apps using API Platform or extensive Doctrine collections.
We will serialize a collection of 50 Order entities, each containing nested OrderItems and Product relations. This stresses the serializer and the memory manager.
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 |
+----------------------+--------------------+----------------------+----------------+
FrankenPHP: Shows a massive jump over FPM (2.3x) because the Doctrine Metadata and Serializer ClassMetadata are already in memory. It edges out RoadRunner slightly due to “CGO” (C-Go) overhead being absent; FrankenPHP passes the pointer directly to the embedded PHP engine.
RoadRunner: Extremely stable. While slightly slower than FrankenPHP here, its memory footprint was flatter. The breakdown suggests that passing large JSON payloads over the RPC pipes (Standard Streams/TCP) incurs a tiny serialization penalty that FrankenPHP avoids.
Scenario G: The “Keep-Alive” & Memory Leak Stress Test
Long-running PHP scripts leak memory. It is a fact of life. Both servers have mechanisms to kill and replace workers (TTL/Max Requests). We test how “graceful” this recycling is.
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):
- RoadRunner: pool.max_jobs: 50
- FrankenPHP: FRANKENPHP_CONFIG=”worker ./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: The spiral/roadrunner process manager is incredibly mature. It performs “soft resets” — it spins up a new worker before killing the old one (overlapping). This results in almost imperceptible latency spikes for the user.
- FrankenPHP: Also handles restarts well, but we observed a slightly higher “jitter” (variance) when multiple threads decided to restart simultaneously.
Conclusion
The battle between FrankenPHP and RoadRunner in the Symfony 8 ecosystem is not about “fast vs. slow” — both are incredibly fast. It is about Philosophy and Architecture.
The Case for FrankenPHP
- Best For: Modern “Cloud-Native” apps, developers who want Simplicity and projects that need HTTP/3 / Early Hints.
- Killer Feature: The Single Binary. Being able to ship one Docker image that contains the Web Server (Caddy) and the App Server (PHP) is a deployment dream.
- Performance: Slightly higher raw throughput on small payloads due to embedded architecture.
The “Modern Standard.” Likely to become the default for Symfony Docker setups.
The Case for RoadRunner
- Best For: Enterprise Microservices, High-Traffic Systems requiring strict SLAs and heavy background processing.
- Killer Feature: The Ecosystem. If you need a gRPC server, a Kafka consumer, a distributed Key-Value store and a Metrics exporter all in one binary, RoadRunner is unmatched.
- Stability: Its process manager is battle-hardened.
The “Industrial Grade” Choice. If you are building a banking API or a high-throughput queue system, choose RoadRunner.
Start with FrankenPHP. It lowers the barrier to entry for high-performance PHP. Switch to RoadRunner if you need the specific advanced features (RPC/Queues) or if you encounter edge cases in Caddy’s configuration.
Source Code: You can find the full implementation and follow the project’s progress on GitHub: [
Let’s Connect!
If you found this helpful or have questions about the implementation, I’d love to hear from you. Let’s stay in touch and keep the conversation going across these platforms:
- LinkedIn: [
https://www.linkedin.com/in/matthew-mochalkin/ ] - X (Twitter): [
https://x.com/MattLeads ] - Telegram: [
https://t.me/MattLeads ] - GitHub: [
https://github.com/mattleads ]