Question
Session write failed error under concurrent requests in CakePHP file session handler
Lax Vale
0 reputation · 07 May 2020, 19:15 UTC
45.8K views1
Loading…
0 reputation · 07 May 2020, 19:15 UTC
Goal: Assess whether CakePHP’s default file‑based session handler can maintain acceptable response latency under high concurrent request volumes without encountering lock‑related ‘Session write failed’ errors.
Constraints: The application runs on PHP‑FPM with the default session.save_path, uses CakePHP 4.x, and the team prefers to avoid adding external infrastructure unless proven necessary. Uncertainty remains about the concurrency level at which lock contention becomes noticeable, whether adjusting PHP’s session.lock_timeout or CakePHP’s Session configuration can alleviate the latency, and if migrating to a Redis, Memcached, or database session store is the only reliable remedy.
What concurrent request threshold triggers measurable latency increase and ‘Session write failed’ errors with the default file handler?
Does increasing PHP’s session.lock_timeout or configuring CakePHP’s Session.handler to use the native ‘php’ handler reduce lock‑induced latency without changing the storage backend?
Is configuring an external session store (Redis, Memcached, or database) the only reliable solution to eliminate lock‑induced latency under sustained load?
34775 reputation · 08 May 2020, 01:49 UTC
The "Session write failed" error in CakePHP 4.x using the default file handler is almost always a symptom of session locking. PHP's native file session handler implements an exclusive lock on the session file the moment session_start() is called. This lock is held until the script finishes or the session is explicitly closed.
There is no universal request threshold (e.g., "100 requests per second") that triggers this error because the bottleneck is per-session, not per-server. If a single user triggers five concurrent AJAX requests, the second through fifth requests must queue linearly. Latency increases measurably as soon as the execution time of the first request exceeds the patience of the subsequent requests or the PHP-FPM worker timeout.
Adjusting settings without changing the backend generally yields diminishing returns:
cakephpsession.lock_timeout: This may reduce the frequency of "write failed" errors, but it increases latency. Requests will wait longer in a blocked state, which can lead to PHP-FPM worker exhaustion, effectively taking the site offline under load.'php' simply tells the framework to use PHP's internal session management. If the underlying session.save_handler in php.ini is still files, the locking behavior remains identical.To eliminate lock-induced latency, you must move away from exclusive filesystem locks. An external store is the most reliable remedy:
session_write_close() (or the CakePHP equivalent) as soon as you no longer need to write to the session. This releases the lock for concurrent requests.To confirm that locking is the culprit, use a tool like k6 or ab to send concurrent requests using the same session cookie. Monitor the PHP-FPM slow log to see if processes are stalling at the session start phase.
Missing Diagnostic: Are the failing requests originating from a single user session (e.g., multiple simultaneous AJAX calls) or across many different users?
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 08 May 2020, 01:32 UTC
"Session write failed" with the file handler is frequently a filesystem problem rather than a pure concurrency threshold. Distinct session IDs do not contend, so the bottleneck is per-session, but errors also appear when session.save_path is full, has wrong ownership, hits inodes limits, or is blocked by open_basedir.
A useful check before tuning locks:
ini_get('session.save_handler') and ini_get('session.save_path'), and verify the directory is writable by the PHP-FPM user.session.lock_timeout is not a standard, reliably present PHP ini setting; session.lazy_write only skips unchanged writes and does not remove the read-side lock.