PHP process model per request - Deep Dive

Overview - PHP process model per request

What is it?

PHP process model per request means that each time a web server receives a request for a PHP page, it starts a fresh process to run the PHP code. This process loads the script, executes it from top to bottom, sends the output back to the user, and then ends. No data or state is kept between requests unless explicitly saved outside the process.

Why it matters

This model exists to keep web applications simple and secure by isolating each request. Without it, one request could accidentally affect another, causing bugs or security risks. It also means PHP scripts always start with a clean slate, which helps developers avoid complex state management.

Where it fits

Before learning this, you should understand basic web servers and how PHP scripts run. After this, you can learn about PHP session management, persistent storage, and advanced performance techniques like opcode caching or long-running PHP processes.

Mental Model

Core Idea

Every PHP request runs in a brand-new process that starts fresh, runs the script, sends output, and then ends, leaving no memory of previous requests.

Think of it like...

It's like a chef who cooks a meal from scratch for each customer, cleans the kitchen completely after, and never remembers what was cooked before.

┌───────────────┐
│ Web Server    │
└──────┬────────┘
       │ HTTP Request
       ▼
┌───────────────┐
│ PHP Process   │
│ (new each req)│
│ Load Script   │
│ Execute Code  │
│ Send Output   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Client Browser│

Build-Up - 6 Steps

1

Foundation

What happens on a PHP request

Concept: Introducing the basic flow of a PHP script execution per request.

When a user visits a PHP page, the web server receives the request and starts a new PHP process. This process loads the PHP file, runs the code from top to bottom, generates output (usually HTML), sends it back to the user's browser, and then stops.

Result

Each request is handled independently with no leftover data from previous requests.

Understanding that PHP starts fresh for every request helps explain why variables don't keep their values between page loads.

2

Foundation

Stateless nature of PHP processes

Concept: PHP processes do not keep memory or state between requests by default.

Because each PHP process ends after sending output, all variables, objects, and data in memory are lost. This means PHP scripts are stateless unless you use external storage like files, databases, or sessions.

Result

No automatic memory or data sharing between requests.

Knowing PHP is stateless by default clarifies why developers need sessions or databases to remember user info.

3

Intermediate

How PHP integrates with web servers

🤔Before reading on: do you think PHP runs inside the web server process or separately? Commit to your answer.

Concept: PHP can run as a separate process or module depending on the server setup.

PHP can run as a CGI process, FastCGI, or as an Apache module. In CGI/FastCGI, the server starts a new PHP process per request or reuses a pool. As a module, PHP runs inside the web server process but still resets state per request.

Result

Different setups affect performance but the per-request model stays consistent.

Understanding server integration explains performance differences and why PHP still resets state even inside server modules.

4

Intermediate

Role of PHP opcode caching

🤔Before reading on: does opcode caching keep your variables between requests? Commit to your answer.

Concept: Opcode caching stores compiled PHP code to speed up execution but does not keep runtime data between requests.

Opcode caches like OPcache save the compiled version of PHP scripts in memory so PHP doesn't recompile them every time. However, each request still runs in a fresh process with fresh variables.

Result

Scripts run faster but still start with a clean state each request.

Knowing opcode caching only speeds up code loading prevents confusion about persistent variables.

5

Advanced

Persistent data via sessions and storage

🤔Before reading on: do you think PHP automatically remembers user data between requests? Commit to your answer.

Concept: PHP uses external mechanisms like sessions and databases to keep data across requests because processes are short-lived.

To remember user info, PHP uses sessions that store data on the server linked by a cookie. Databases or files also save data permanently. This is necessary because PHP processes forget everything after finishing.

Result

User data persists across page loads despite PHP's stateless process model.

Understanding external storage is essential to build interactive, stateful web apps with PHP.

6

Expert

Long-running PHP processes and workers

🤔Before reading on: can PHP processes run continuously to handle multiple requests? Commit to your answer.

Concept: Advanced PHP setups use long-running processes or workers to improve performance but must manage state carefully.

Tools like PHP-FPM keep PHP processes alive to handle many requests, reducing startup cost. However, developers must avoid relying on in-memory variables to persist between requests, as this can cause bugs or memory leaks.

Result

Better performance but requires careful coding to avoid state-related errors.

Knowing the difference between per-request and long-running PHP processes helps avoid subtle bugs in production.

Under the Hood

When a request arrives, the web server invokes the PHP interpreter as a new process or uses a persistent process pool. The PHP engine reads the script, compiles it into opcode, executes it, and sends output. After execution, the process cleans up memory and exits or waits for the next request if persistent. No variables or runtime data survive beyond this cycle unless saved externally.

Why designed this way?

PHP was designed for simplicity and security, isolating each request to prevent data leaks and side effects. Early web hosting environments favored this model for easy resource management and crash isolation. Alternatives like persistent processes existed but added complexity and risk, so PHP kept the per-request model as default.

┌───────────────┐
│ HTTP Request  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Web Server    │
│ (e.g. Apache) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ PHP Interpreter│
│ (new process) │
│ Compile & Run │
│ Send Output   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ HTTP Response │

Myth Busters - 4 Common Misconceptions

Quick: Does PHP keep your variables in memory between page loads? Commit to yes or no.

Common Belief: PHP remembers all variables and data automatically between requests.

Reality: PHP processes start fresh for each request, so variables do not persist unless saved externally.

Why it matters: Assuming variables persist causes bugs where data disappears unexpectedly between pages.

Quick: Does opcode caching keep your PHP variables alive between requests? Commit to yes or no.

Common Belief: Opcode caching means PHP remembers all data and variables between requests.

Reality: Opcode caching only saves compiled code, not runtime data or variables.

Why it matters: Confusing opcode caching with data persistence leads to wrong assumptions about state management.

Quick: Can PHP processes run continuously and handle multiple requests without restarting? Commit to yes or no.

Common Belief: Each PHP process handles only one request and then dies immediately, no exceptions.

Reality: With PHP-FPM or similar, processes can stay alive and handle many requests, but still reset state per request.

Why it matters: Not knowing this can cause confusion about performance tuning and memory leaks in production.

Quick: Does running PHP as an Apache module mean variables persist between requests? Commit to yes or no.

Common Belief: Running PHP inside the web server means variables stay in memory across requests.

Reality: Even as a module, PHP resets all variables each request to keep isolation.

Why it matters: Believing otherwise can cause security risks and unpredictable behavior.

Expert Zone

1

PHP's per-request model simplifies crash recovery because each request is isolated; a crash affects only that request.

2

Long-running PHP processes require explicit memory management to avoid leaks since the process does not restart automatically.

3

Session data is stored outside PHP processes, often in files or databases, to maintain user state across stateless requests.

When NOT to use

Avoid relying on PHP's per-request model for real-time or persistent connections like WebSockets; instead, use specialized servers or frameworks designed for long-lived connections such as ReactPHP or Swoole.

Production Patterns

In production, PHP-FPM is commonly used to keep pools of PHP processes alive for better performance, combined with opcode caching and external session storage to balance speed and statelessness.

Connections

HTTP Protocol

PHP's per-request model aligns with HTTP's stateless request-response nature.

Understanding HTTP's statelessness helps grasp why PHP resets state each request and needs external storage for persistence.

Operating System Process Model

PHP processes per request mirror OS process isolation and lifecycle management.

Knowing how OS processes start and end clarifies PHP's fresh environment per request and resource cleanup.

Functional Programming

PHP's stateless request model resembles pure functions that have no side effects or memory between calls.

Seeing PHP scripts as pure functions per request helps understand why side effects must be managed externally.

Common Pitfalls

#1 Expecting variables to keep their values between page loads.

Wrong approach:

Correct approach:

Root cause:

Misunderstanding that PHP variables reset every request and not using sessions or external storage.

#2 Assuming opcode caching keeps runtime data alive.

Wrong approach:

Correct approach:

Root cause:

Confusing compiled code caching with runtime data persistence.

#3 Storing large data in global variables expecting persistence in PHP-FPM.

Wrong approach:

Correct approach:

Root cause:

Not realizing PHP-FPM processes reset variables per request despite process persistence.

Key Takeaways

PHP runs each request in a new process or fresh environment, so no variables or data persist automatically between requests.

This per-request model keeps web applications simple, secure, and isolated but requires external storage for state.

Opcode caching speeds up PHP by saving compiled code but does not keep runtime data alive.

Advanced setups use persistent PHP processes for performance but still reset state per request to avoid bugs.

Understanding this model is essential to correctly manage user sessions, data persistence, and performance in PHP applications.