PHP Session Performance & Locking

Also Known As

TL;DR

Explanation

By default PHP stores sessions as files and acquires an exclusive flock() lock when session_start() is called. This serialises all concurrent requests from the same user — an AJAX-heavy page making 5 simultaneous requests will queue them, each waiting for the previous to call session_write_close(). Fixes: call session_write_close() as early as possible once session data is no longer needed; use session_start(['read_and_close' => true]) for read-only requests; switch to a Redis or Memcached session handler (configurable via session.save_handler) which supports more granular locking or lock-free read operations. Redis sessions also enable horizontal scaling across multiple PHP-FPM servers without sticky sessions.

Common Misconception

Why It Matters

Common Mistakes

• Using file-based sessions for applications with concurrent AJAX requests — each request waits for the session lock.
• Not calling session_write_close() early when session data is no longer needed in a long request.
• Storing large objects in sessions — every request deserialises the entire session payload.
• Not using Redis or Memcached sessions for multi-server deployments — file sessions are per-server.

Code Examples

session_start(); // lock held for entire request
$data = $_SESSION['user'];
expensiveOperation(); // session locked while this runs

session_start();
$data = $_SESSION['user'];
session_write_close(); // release lock immediately
expensiveOperation();

References

• ↗ https://www.php.net/manual/en/function.session-write-close.php

Tags

Related Terms