AI 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.
Chapters
PHP session locking by default causes AJAX requests that could run in parallel to execute sequentially, hurting performance.
Session locking prevents lost updates when multiple requests modify the same session data concurrently, e.g., a shopping cart incrementing item quantities.
Browsers typically open 6-12 parallel connections to the same host, enabling parallel AJAX requests, but session locking negates this benefit.
Calling session_write_close() releases the session lock, allowing subsequent requests to run in parallel, but any writes after that are lost.
Demonstrates adding session_write_close() to a weather dashboard app, showing requests completing within milliseconds of each other.
Using Memcached or Redis sessions does not automatically fix locking; locking behavior varies by backend and extension.
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.
In Magento, even read-only AJAX endpoints experience blocking due to locking, causing significant delays across users.
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.
Mentioned in this Video
Tutorial Checklist
Study Flashcards (6)
What is PHP session locking?
easy
Click to reveal answer
What is PHP session locking?
A mechanism that prevents concurrent requests from modifying the same session data simultaneously, avoiding lost updates.
00:14
What function releases the session lock in PHP?
easy
Click to reveal answer
What function releases the session lock in PHP?
session_write_close()
03:15
How many parallel connections do browsers typically open to a single host?
medium
Click to reveal answer
How many parallel connections do browsers typically open to a single host?
6 to 12 parallel requests.
02:08
Does using Memcached or Redis sessions automatically fix session locking?
medium
Click to reveal answer
Does using Memcached or Redis sessions automatically fix session locking?
No, locking behavior varies by backend and extension; some still lock by default.
04:44
Which PHP session backend locks by default?
medium
Click to reveal answer
Which PHP session backend locks by default?
File-based sessions lock by default using file system locks.
05:15
What is the downside of releasing the session lock early?
medium
Click to reveal answer
What is the downside of releasing the session lock early?
Any writes to the session after releasing the lock are lost.
03:00
💡 Key Takeaways
Session locking bottleneck
Identifies a common but often overlooked performance issue in PHP applications.
00:02Browser parallel connections
Explains the theoretical benefit of parallel AJAX requests that session locking negates.
01:55Releasing the lock
Provides a concrete solution (session_write_close) with a practical example.
03:15Memcached/Redis workaround
Debunks a common misconception that switching backends fixes locking.
04:28Backend locking differences
Highlights the complexity of locking behavior across different extensions and frameworks.
05:15Full Transcript
[00:02] bottleneck in many PHP applications. Ajax requests that could actually run in parallel are running sequentially one after the other because PHP is enabling
[00:14] 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
[00:27] 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.
[00:43] 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
[00:58] 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
[01:12] 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
[01:27] 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
[01:41] 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.
[01:55] 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
[02:08] 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
[02:20] 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
[02:32] 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
[02:45] 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
[03:00] 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
[03:15] 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
[03:30] 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
[03:45] rendering the output. We can add session right close here now this runs in the browser. Refreshing the weather dashboard application. We can
[04:00] 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,
[04:13] 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
[04:28] 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
[04:44] 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
[04:59] 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
[05:15] 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
[05:31] 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
[05:44] 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
[05:59] 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
[06:14] 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
[06:26] 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
[06:40] 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
[06:55] 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.
