---
title: 'Are Session Locks Secretly Hurting your PHP App Performance?'
source: 'https://youtube.com/watch?v=3k-JTYm9WCA'
video_id: '3k-JTYm9WCA'
date: 2026-08-03
duration_sec: 426
---

# Are Session Locks Secretly Hurting your PHP App Performance?

> Source: [Are Session Locks Secretly Hurting your PHP App Performance?](https://youtube.com/watch?v=3k-JTYm9WCA)

## Summary

This video explains PHP session locking, a common performance bottleneck in PHP applications where parallel AJAX requests are forced to run sequentially. The presenter, Benjamin, discusses what session locking is, its performance implications, and why common workarounds like using Memcached or Redis sessions may not solve the problem as expected. He demonstrates how to release session locks manually and reviews locking behavior across different session backends and frameworks.

### Key Points

- **Session locking bottleneck** [00:02] — PHP session locking by default causes AJAX requests that could run in parallel to execute sequentially, hurting performance.
- **Purpose of session locking** [00:14] — Session locking prevents lost updates when multiple requests modify the same session data concurrently, e.g., a shopping cart incrementing item quantities.
- **Browser parallel connections** [01:55] — Browsers typically open 6-12 parallel connections to the same host, enabling parallel AJAX requests, but session locking negates this benefit.
- **Releasing session lock** [02:45] — Calling session_write_close() releases the session lock, allowing subsequent requests to run in parallel, but any writes after that are lost.
- **Example code** [03:15] — Demonstrates adding session_write_close() to a weather dashboard app, showing requests completing within milliseconds of each other.
- **Memcached/Redis workaround** [04:28] — Using Memcached or Redis sessions does not automatically fix locking; locking behavior varies by backend and extension.
- **Locking by backend** [05:15] — File-based sessions lock by default; PHP Redis extension does not lock by default (but can be enabled); Memcached D extension always locks; Magento's C Redis library implements locking.
- **Real-world impact** [06:26] — In Magento, even read-only AJAX endpoints experience blocking due to locking, causing significant delays across users.

### Conclusion

Session locking is a hidden performance killer in PHP apps. To fix it, either explicitly close the session when no longer needed or use a non-locking driver, but always research how your specific framework and backend handle locking.

## Transcript

bottleneck in many PHP applications. Ajax requests that could actually run in parallel are running sequentially one after the other because PHP is enabling
locking of sessions by default. In this video, I'm going to explain what PHP session locking is, its performance implications, and why a common implications, and why a common workaround of just use memcache sessions
is not going to work as you would expected to. Mo, I am Benjamin, and my work is focused on PHP performance topics for the last 10 years, helping thousands of developers, customers, and open-source projects uh along the way.
The simplicity and power of PHP sessions should not be underestimated. Given how languages struggle with this topic even today, this fundamental building block of the PHP language has been there since the beginning and we've come to rely on
its power. But with everything that may be a little bit underrated due to being around forever, there has been bits to stumble over, notably session locking. At the core, the use case for session locking
seems obvious. You don't want sessions that run in parallel to cause lost updates due to them changing the same data in the session structure. An oversimplified example of this is a shopping cart storing the items and
purchase. ignoring the complete lack of security checks. Here, this script gets the product item from the request, then increments the quantity by one on the cart. When you allow incrementing the
number of items on the cart overview page, for example, then a visitor with very fast mouse trigger fingers could easily have a lost update because two requests modify the data at the same time and overwrite each other's changes.
Browsers usually run a number of connections in parallel to a single host. The exact number has been changing over the last years and depends on the browser and the HTTP protocol being used. In this 16-year-old Stack Overflow
thread, for example, you find a 2020 update. And it says that we should expect at least 6 to 12 parallel requests to the same host when using
Ajax. In theory, this is a great hack to decrease the time to first bite on the first page of rendering by outputting empty spaces and then lazy
by outputting empty spaces and then lazy loading the content using Ajax. And if that would run in parallel, you could have a great workaround for PHP's lack of multi-threading. Looking at the networking tab for our weather dashboard
example, it shows a different picture, though. You see the requests arriving after each other. To get the requests to run in parallel, we need to modify our code to release the session lock. This essentially means that the session is
closed for further writing and all rightes that are happening since then after this method is called are being lost. The way to do that is to call the session write close function in PHP core or any of the wrappers that your uh
framework of choice is using. Let's look at the uh example code from my weather at the uh example code from my weather dashboard application. It's a very simple code um opening or starting the session using the core API. Then we're
also sleeping a while to simulate the slowness of a script. And then we have some dummy code here where we have the cities then we pick one city. Uh we also randomly select um a weather condition and a temperature and then we are
rendering the output. We can add session right close here now this runs in the browser. Refreshing the weather dashboard application. We can
see the responses coming in quite quickly. And if we do that again with quickly. And if we do that again with the network toolbar open,
finishing within a few milliseconds of each other, showing the parallelism at place here. But explicitly calling session close can be tedious work application, the number of endpoints, and it might even be impossible if
you're using third-party modules or an e-commerce system where you cannot change the code to do that. If you're looking for a generic solution, then the internet will give you advice like use memcache or redd sessions as um a way to
fix session locking. But this is not generally the right advice depending on what session back end you're using or what framework you use on top. Session locking is still implemented for memcache and reddis sessions and you
cases to understand is the session locking in place or not and do you need to call the right close method uh individually. We've seen the default session back end using files uh in PHP core is using locking by default
implemented using file system locks. The PHP Reddus extension is not locking by default and locking hasn't been implemented in it uh for a long time. There is now an any setting radius session locking enabled which you can
session locking enabled which you can set to one to uh make this feature work. With Symfony, you can use Reddus sessions as well and they will not be locking either by default. If you are using the mem cache D
extension, then it will always be locking by default and you cannot change that to true if Magento sessions are often using Reddus, but uh the C Reddus library that is used under the hood is implementing locking. So it's different
implementing locking. So it's different than the PHP Reddus extension. And even for Ajax endpoints in the Magento framework that are clearly just for reading data using Ajax, the locking will be in place by default. You can see
the section load controller in tideways here spending most of its time sleeping which is how the C revising locking at the lowest level. So um
you're seeing a lots of blocking here across many users. This is a problem that is so common that there's even a module available from integeret that is disabling session blocking for section node controllers. These are the two
options that you have. Close the session or use a non-locking driver with all the problems that this might have. It is important that you research how session locking is working in the application or framework that you are using. If you're
interested in other PHP performance topics, there's a video suggestion from our channel here. And you can subscribe to this channel or our newsletter below. to this channel or our newsletter below. See you.