0

I'm working with my application in high availability, and for that I configured Redis as a session manager.

Redis is installed on its own server on the same network, but I noticed that when there is more than one AJAX request to the PHP application, it takes much longer. About 11 requests take about 10s in total to complete.

If I use PHP with the native session, the 11 requests are completed in less than 400ms. Thinking that the problem was Redis, I decided to configure Memcached as a session manager, again on its own server, but again the same problem occurs.

How can I fix this issue and get faster session management?

Tom
  • 641
  • 2
  • 8
  • 21

1 Answers1

0

That sounds as-if you still have sticky sessions active and everything that is not on the same host involves networking and that seems slow. Therefore sticky sessions in your load balancer will get you faster session management and should fix this issue.

However that is only one option. It could be you don't have sticky sessions any longer, and therefore using the session handler for local files is with race-conditions (but faster). Then the explanation for the network bases session handlers being slower is not because of the network but because the locking is effective and the sessions don't get broken.

Likely the second is the case, but you should know better, I don't have the insights.

So, if you want to tackle with it on the different axis: Mind that sessions in PHP are locking. You normally want that as the default, but if you dig a bit into the topic you might find some more useful information.

Here an existing Q&A that details on it: PHP & Sessions: Is there any way to disable PHP session locking?

One approach outlined in there is to differentiate between read and write requests. The read only requests don't need to block all the time (perhaps). See there for better explanation and more detailed discussion.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • I made some changes to the application. CodeIgniter (framework used by the app) says it doesn't use the session defined in php.ini. With that I stopped using the settings defined by the CI. In all classes, the first thing I do now is trigger the `session_start();` take all values ​​of `$_SESSION`, store them in a model and execute the `session_write_close()` function. If I need to write something in the session, I redo `session_start()` again, write and send session_write_close(). Session writing is rarely done, 90% of session writing is usually done on login only. – Tom Aug 15 '23 at 20:20
  • With these changes the 11 requests now have a time between 250ms, sometimes in 1s. I don't know if it's the best thing to do, but the result is undeniable. – Tom Aug 15 '23 at 20:20
  • Yes, that's basically it and also yes, we then have to learn how the application behaves. I personally perhaps would make the login transaction blocking full-through so that other requests of that user have to wait, and consider to work with [_eventual consistency_](https://en.wikipedia.org/wiki/Eventual_consistency) (Wikipedia) otherwise. But YMMV, it is really with the application and CodeIgniter is long ago I did it. – hakre Aug 15 '23 at 20:45