S M Tahosin

Posted on Nov 9

PHP Dies After Every Request. How the Zend Engine Actually Runs Your Code.

#php #webdev #programming #architecture

For more than two decades, programmers coming from languages like Java, Python, Go, and Node.js have looked at PHP and repeated the exact same criticism:

"PHP does not even have a persistent application server. It boots up, runs a script, and dies after every single HTTP request. How could anyone build serious software on an architecture like that?"

The irony is that those critics missed the most profound design decision in modern web computing.

What looked like a primitive limitation was, in reality, a deliberate architectural choice called the Shared-Nothing Architecture.

While other language runtimes battle memory leaks that accumulate over weeks, global state that accidentally bleeds between concurrent users, and fatal unhandled exceptions that knock down entire server clusters, PHP operates on a radically different premise:

PHP executes in total isolation, reclaims every single byte of memory at the end of the request, and resets to a pristine blank slate.

Yet modern PHP is not slow. Over the last decade, the core engineering team completely rebuilt the runtime from the ground up:

The Zend Engine was rewritten with cache-optimized 16-byte zval structures.
OPcache eliminates file parsing by caching bytecode directly inside shared operating system memory.
Copy-on-Write ensures massive arrays consume zero extra RAM until mutated.
PHP 8's Tracing JIT compiles hot execution loops directly into native silicon machine code.

To truly understand why PHP powers over 75% of the web, you have to look beneath the surface syntax and examine how the Zend Engine and PHP-FPM actually execute your code under the hood.

Here is the complete journey of a PHP request.

The Shared-Nothing Philosophy: Why Dying on Purpose Is a Superpower

To appreciate the Zend Engine, you must first understand the architectural divide between long-lived persistent runtimes and PHP.

In Node.js, Python (FastAPI/Django), Ruby (Puma), and Go, your application boots once. The runtime initializes global variables, establishes database connection pools, loads framework classes, and starts an event loop or worker thread pool that lives for days or months.

This model is fast, but it carries profound architectural vulnerabilities:

State Leaks Across Users: If a developer accidentally mutates a global object or attaches data to an uncleaned request context, User B can end up reading private data belonging to User A.
Slow-Motion Memory Leaks: If a third-party package slowly appends items to a cache that never gets cleared, the process slowly exhausts RAM until an Out-Of-Memory (OOM) killer terminates the process.
Catastrophic Blast Radius: If an unhandled exception causes a fatal crash or memory corruption, the entire server process dies, severing thousands of active connections simultaneously.

PHP took the opposite path: The Shared-Nothing Process Model.

When an HTTP request arrives at a PHP worker:

The worker allocates a fresh, completely isolated memory arena called the Request Heap (managed by Zend Memory Manager, ZendMM).
Superglobals ($_GET, $_POST, $_SERVER) are populated freshly for that specific request.
Your application executes in total isolation. No other concurrent user shares that memory space.
The HTTP response headers and body are flushed to the web server.
The Zend Engine instantly tears down the request heap. Every variable, object, database handle, and memory buffer is wiped out in a single sweep.
The worker process returns to its pristine resting state, ready for the next request.

This design gives PHP an almost indestructible reliability.

Memory leaks simply cannot survive across requests. If a buggy piece of code allocates 50 megabytes of temporary data and forgets to clean it up, the Zend Engine sweeps it away automatically the instant the response finishes.

And if a script encounters a fatal error or segmentation fault, it kills only that single worker. The master process respawns a replacement in under a millisecond without dropping any other concurrent user request.

The Compilation Pipeline: From PHP Text to Zend Opcodes

A common misconception is that because PHP dies after every request, it must re-read and re-parse your .php files from disk every time someone loads a page.

In PHP 3 and 4, that was true. In modern PHP, that model has been dead for over a decade.

When PHP processes a file, it passes through four distinct phases:

[PHP File] ──> [Lexer: Tokens] ──> [Parser: AST] ──> [Compiler: Opcodes] ──> [Zend VM Executor]

1. Lexing (Tokenization)

The Zend Lexer scans your raw PHP script and converts the character stream into a sequence of language tokens (such as T_VARIABLE, T_OBJECT_OPERATOR, T_STRING).

2. Parsing (Abstract Syntax Tree)

Introduced in PHP 7, the Zend Parser reads the tokens and constructs a hierarchical Abstract Syntax Tree (AST). The AST validates syntax, resolves operator precedence, and organizes your program logic into a structured tree before code generation.

3. Compilation (Zend Opcodes)

The compiler walks the AST and emits Zend Opcodes. An opcode is a low-level virtual machine instruction, comparable to Java bytecode or Python bytecode.

For example, this simple addition:

$c = $a + $b;

compiles into low-level instructions that look like this:

ZEND_ADD      $a, $b, ~0
ZEND_ASSIGN   $c, ~0

4. The Game Changer: OPcache in Shared Memory

In a stock PHP installation without caching, compiling source files on every request would indeed create heavy CPU overhead.

This is where OPcache enters the picture.

OPcache intercepts the compilation pipeline. The first time a PHP file is loaded, OPcache compiles it into Zend Opcodes and stores the compiled bytecode directly inside Shared Memory (SHM).

When subsequent requests arrive:

PHP skips the Lexer entirely.
PHP skips the Parser and AST construction entirely.
PHP skips the Compiler entirely.

Instead, the Zend VM executor fetches the pre-compiled opcodes directly from memory and executes them immediately.

With Preloading (introduced in PHP 7.4 and standard in modern frameworks like Laravel and Symfony), frameworks can compile all core classes, traits, and interfaces on server boot into permanent shared memory.

When a user request hits your application, the entire framework is already resident in RAM, ready to execute with zero initialization latency.

The 16-Byte Miracle: How the Zend Engine Stores Variables

In PHP, a variable can be an integer, a floating-point number, a string, an array, an object, or null. It can change its type dynamically at runtime:

$x = 42;
$x = "Hello World";
$x = [1, 2, 3];

How does a statically-compiled C program (which the Zend Engine is) represent a dynamically-typed variable with minimal memory overhead?

The answer is the zval (Zend Value).

In PHP 5, a zval was a bloated C structure requiring 32 to 48 bytes on 64-bit systems. Worse, every single zval was allocated as an independent block on the heap, scattering pointers across memory and causing frequent CPU cache misses.

In PHP 7, core engineer Dmitry Stogov led a complete rewrite of the Zend Engine known as phpng (PHP Next Generation). The zval was completely redesigned into an ultra-compact, 16-byte structure.

Here is what a zval looks like under the hood in C:

struct _zval_struct {
    zend_value value;            /* 8 bytes: union holding primitive or pointer */
    union {
        struct {
            zend_uchar type;     /* 1 byte: IS_LONG, IS_STRING, IS_ARRAY, etc. */
            zend_uchar type_flags;
            zend_uchar const_flags;
            zend_uchar reserved;
        } v;
        uint32_t type_info;      /* 4 bytes total */
    } u1;
    union {
        uint32_t next;           /* hash collision chaining */
        uint32_t cache_slot;     /* literal cache */
        ...
    } u2;                        /* 4 bytes total */
};

Notice the engineering elegance of this layout:

Exactly 16 bytes total on any 64-bit architecture.
For primitive integers (IS_LONG) and floats (IS_DOUBLE), the number is stored directly inside the 8-byte value field. There is zero pointer indirection and zero heap allocation!
For complex types like strings (IS_STRING) or arrays (IS_ARRAY), the value field stores a pointer to a dedicated payload structure (zend_string or zend_array).
The zval itself is allocated directly on the CPU execution stack or embedded inside contiguous array memory. It does not require separate heap allocation calls.

This single refactoring doubled PHP's raw execution speed and cut memory consumption in half across the entire world on the day PHP 7 was released.

Copy-on-Write: The Art of Memory Laziness

Consider this PHP code:

$users = get_large_user_dataset(); // A massive 100,000-item array (~20 MB)
$backup = $users;                  // What happens here?

In many languages, assigning an array to a new variable either duplicates the entire array in memory (wasting 20 MB of RAM) or passes a mutable reference where changes to $backup mutate $users.

In PHP, arrays have value semantics: modifying $backup will never mutate $users.

Does that mean PHP duplicates 20 megabytes of memory on $backup = $users?

The answer is no, thanks to Copy-on-Write (COW).

Here is how Copy-on-Write works in the Zend Engine:

Assignment without Duplication: When you write $backup = $users, PHP simply copies the 16-byte zval. Both $users and $backup point to the exact same physical zend_array in memory.
Refcount Increment: PHP increments the array's reference counter: gc.refcount = 2. No array data is duplicated. The operation takes mere nanoseconds.
The Mutation Trigger: As long as both variables only read from the array, they share the same physical memory block forever.
Physical Separation: The moment you mutate one of the variables:

$backup[0] = "Modified User";

The Zend Engine checks the refcount. Because refcount > 1, PHP knows that multiple variables point to this memory.

Only at that exact moment does PHP clone the array in memory, allocate a fresh block for $backup, decrement $users's refcount to 1, and apply the mutation to the new clone.

If you pass a 50-megabyte array through ten functions that only read data, PHP never duplicates that array once. You get the safety of pure pass-by-value semantics with the speed and efficiency of pass-by-reference pointers.

PHP-FPM: The Resilient Worker Pool

How does a web server like Nginx or Caddy communicate with PHP in production?

The bridge is PHP-FPM (FastCGI Process Manager).

PHP does not run as an Apache module anymore. Modern production architectures run PHP as an independent daemon managing a pool of isolated worker processes.

The PHP-FPM architecture operates on a master-worker model:

The Master Process: Runs as a privileged supervisor. It binds to a UNIX domain socket or TCP port, parses php.ini configurations, loads OPcache into shared memory, and spawns worker processes.
The Worker Pool: A collection of pre-forked worker processes that listen for incoming FastCGI connections.
Request Distribution: When Nginx receives an HTTP request for a .php endpoint, it translates the request into binary FastCGI frames and forwards it over the socket to an idle PHP-FPM worker.
Execution and Cleanup: The worker executes the script, streams the generated HTML or JSON back to Nginx, runs its memory cleanup routines, and marks itself ready for the next request.

Fault Tolerance by Design

The real beauty of PHP-FPM is its fault isolation.

In a long-lived Node.js or Python process, if a native C extension crashes with a segmentation fault, the entire server process dies instantly. All ongoing requests for every user are abruptly dropped.

In PHP-FPM, if Worker 4104 encounters a fatal segmentation fault or exceeds its memory limit, only that single worker terminates.

The master process detects the signal, logs the crash, and spawns a brand new worker in fractions of a millisecond. None of the other workers are affected, and no other users experience downtime.

PHP 8's Tracing JIT: Compiling Bytecode to Native Silicon

With PHP 8, the language took its biggest evolutionary leap since PHP 7: the introduction of a Just-In-Time (JIT) Compiler.

In standard execution, the Zend VM is an interpreter. It runs an infinite loop in C that fetches an opcode, looks up the opcode handler in a table, and executes it:

while (1) {
    execute(opline++);
}

While this interpreter loop is heavily optimized, it still incurs CPU overhead: jumping through handler tables and maintaining VM stack frames.

The PHP 8 JIT bypasses this interpreter loop for performance-critical code.

PHP 8 implements a Tracing JIT:

Profile Recording: As the Zend VM executes opcodes, the JIT monitors frequently executed code paths (known as hot loops or hot traces).
Intermediate Representation: When an opcode sequence exceeds a designated execution threshold, the JIT records the exact type profile of the variables involved.
Native Assembly Generation: Using DynASM (the assembler library originally created for LuaJIT), the JIT translates those opcodes directly into raw machine instructions: x86-64 or ARM64 assembly.
Direct Execution: On subsequent iterations, the CPU executes the machine code directly on physical hardware, completely bypassing the Zend VM interpreter loop.

For typical I/O-bound web applications waiting on database queries, the JIT provides modest gains (around 5% to 15%), because database latency dominates execution time.

However, for CPU-bound tasks like image manipulation, mathematical modeling, JSON parsing, and machine learning inference, the JIT allows PHP to run at speeds approaching native C.

The Paradigm Shift: Why the Architecture Won

PHP's reputation as a "messy" language was earned in the late 1990s when developers mixed raw SQL directly into HTML templates.

Yet while developer trends have cycled through countless runtimes, frameworks, and deployment paradigms, PHP has quietly remained the workhorse of the internet.

Why? Because its core architectural philosophy was right all along:

Shared-Nothing means bulletproof reliability. No memory leaks across requests, no cross-user state pollution, and instant crash isolation.
OPcache delivers compiled-language speed. Source files are compiled once into shared memory, eliminating disk I/O and parsing overhead.
The 16-byte zval maximizes cache locality. Small primitives never touch the heap, keeping CPU caches full and latency low.
Copy-on-Write provides safety without waste. You get clean pass-by-value semantics without duplicating memory blocks.
PHP-FPM scales effortlessly. Pre-forked worker pools map cleanly to multi-core servers without complex multi-threading bugs.

PHP does not survive despite its execution model. It thrives because of it.

By accepting that every request is an ephemeral, isolated event, PHP achieved what long-lived runtimes still struggle to guarantee: effortless scalability, rock-solid stability, and a developer experience where you never have to restart the server to see your code run.

When you look at modern PHP through the lens of the Zend Engine, what was the biggest revelation that changed your perspective on how the language actually works? And how do you see the balance between shared-nothing runtimes and persistent app servers evolving?

References:

DEV Community