Level 102
What is the update query ? There is most likely a good reason..
But an easy solution is to use another driver
Jan 3, 2022
11
Level 1
Session Read and Write on every request
I use database as the session driver. I noticed something strange recently.
The session manager in Laravel sends an update to the session store with every single request. This is done even if no session variables are changed in that request.
This adds an unnecessary load on the database. Can we make it such that the session store is only updated if a session variable is changed in that request?
Level 1
update `phpsessions` set `payload` = ?, `last_activity` = ?, `user_id` = ?, `ip_address` = ?, `user_agent` = ? where `id` = ?
The payload has not changed.
Maybe the update query runs to update the last_activity field? But thats a lot of overhead just to track last_activity.
Level 102
@mittalvishesh I don't think you can disable that in any way, except by changing the implementation yourself. You can of course make PR to change how it works generally in laravel, but I would think you would need to change it for the whole sessions handling. Of you look at the StartSession class, you will see that it runs the saveSession() as part of the handleStatefulRequest() method. So it does seem that it will always ask the session driver to save, no matter what.
Level 122
Session is updated to extend the expiry time. Session lifetime is 120 minutes by default so if you load a page the time will be set 2 hours in the future. If you wait 5 minutes and then load a page again, the session expiry is modified to make it current time +120 minutes.
So Session is updated for every access. If you are concerned, use a more efficient session store
Edit: Sorry the current time is stored, not the expiry time. But it is still so that the expiry can be calculated.
Level 1
Level 102
@mittalvishesh sounds like a good idea. The database isn't a good choice for sessions unless you need to query the session data manually
If you got the issue solved, you can set the thread as solved by marking a best answer
Level 1
@Sinnbeck We used database we have a requirement to have very long running/persistent sessions (ie - their lifetime is in months). I guess technically, cookie session store can do the same.
Level 102
@mittalvishesh I actually think redis would be able to store for that long without much issue. File is also a possibility
Level 1
redis - I am looking for a more serverless option for session management (one big reason why we are planning to switch out of database driver). Planning redis cluster capacity in advance will be tricky as we are expecting spiky workload.
dynamodb - this solves the serverless requirement. However, the overhead of reading/writing session data is ever larger.
cookie - this seems to solve both the serverless requirement, and has low overhead of reading/writing session data. It does increase the size of network requests - but that seems to be negligible. The only concern I see so far is the hard cap on the payload size. But we can work around that.
Level 102
@mittalvishesh Then I completely agree that cookie is your best bet :)
Level 1
@Sinnbeck Thanks for saying that. Changing session store in a production app is a bit nerve-wracking - so its good to hear that we are moving in the right direction. :)
Please or to participate in this conversation.