[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.