Session write failed error under concurrent requests in CakePHP file session handler

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?