Answer the question
In order to leave comments, you need to log in
Is it optimal to store frequently used large data in a server session using sockets?
Good day to all, I asked myself the question of optimization when working with the database, and began to invent my own bikes so as not to pull the database once again unnecessarily, and the idea of optimizing for reading appeared so that there was practically no reading from the database, reading occurs only at the first load pages
(I’ll say in advance that the page is loaded once, all other manipulations occur by sending commands to sockets and do not require page refresh)
I came up with the following scheme:
So, at this stage I have a client with a session, and a server with a session for this client, the server doesn’t care, it can create at least a billion sessions and work with clients, but the question is, how much better it will store data in these sessions ? or the load on the iron will be even worse than with a direct request to the database?
Answer the question
In order to leave comments, you need to log in
It seems to me that in the general case this is not the right solution, regardless of where the sessions are stored.
The session mechanism is slow, the session always loads ALL the data that it has two.
With a high probability, in half the cases you do not need all the data.
Using memcache, as Vitaly Sivkov says, is also a bad idea, it does not guarantee data storage, you may encounter one day that there is no data in it, but Redis is just right here.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question