4 ms·
>Nowadays you can just throw all your sessions in a Redis node and access them in a fraction of a millisecond from a thousand different servers. You seriously
by papsosouid 13y ago
>Nowadays you can just throw all your sessions in a Redis node and access them in a fraction of a millisecond from a thousand different servers.
You seriously believe that? Adding tons of extra complexity, latency, and potential failure modes to gain absolutely nothing is not a trivial thing.
- kijin 13y agoIf you have enough application servers for session sharing to be a problem, you probably already have enough complexity to worry about. Adding sessions to the mix won't change much. If you don't want to add another daemon to your stack, just reuse whatever you were using before, whether it's Memcached, MongoDB, or plain old MySQL. Gain nothing? Why? Easily preventing CSRF replay attacks count as something, doesn't it?
- josephscott 13y agoYou don't need to have very many application servers for this to become an issue. For instance, what if you host your site in multiple data centers? Each data center might only have a few servers, but any additional data layers that have to be kept in sync between the two is a non-trivial amount of additional complexity.
- papsosouid 13y ago>If you have enough application servers for session sharing to be a problem, you probably already have enough complexity to worry about You definitely have lots of complexity. Which is why adding more is bad. There is no point where things are so complex that making it more complex is cool. > If you don't want to add another daemon to your stack, just reuse whatever you were using before, whether it's Memcached, MongoDB, or plain old MySQL. Sure, just make things slower and more likely to fail for no reason. >Gain nothing? Why? Because you can just store the session in an encrypted cookie. There is no need for it to be on any server at all.