Use Redis Session Handler

[DaSourcerer]

As a redis server is already part of the infrastructure and the redis PHP extension is being installed anyways, it is probably a good idea to use it as a session storage as well. This will introduce no code changes and may help relieve the host system of i/o pressure. Per this example, the following configuration changes are needed:

session.save_handler = redis
session.save_path    = "tcp://127.0.0.1:6379?persistent=1"

This can be further improved by eliminating the TCP/IP overhead when using unix sockets directly:

session.save_path    = "unix:///var/run/redis/redis.sock?persistent=1"

With regards to #24, msgpack could be used as a session serialization format:

session.serialization_handler = msgpack

⚠️ Changing the serialization format will require clearing all sessions!

On a related note it may be worth investigating if the I/O scheduler on the host is adjusted correctly. By default, Linux is using the cfq scheduler which is intended for interactive tasks. Server and virtualized environments may profit from deadline (recommended for Amazon, btw) or even noop. The default is controlled by the elevator kernel parameter. Check the settings for existing devices with cat $(find /sys/devices/ -name scheduler).

[markharding]

Redis is not the session handler, it is a cache for the sessions. See https://github.com/Minds/engine/blob/master/Core/Data/Sessions.php#L12. We use cassandra as a 'hard' session store and redis as a transparent layer.

…

On 22 February 2017 at 15:52, DaSourcerer ***@***.***> wrote: As a redis server is already part of the infrastructure and the redis PHP extension is being installed anyways, it is probably a good idea to use it as a session storage as well. This will introduce no code changes and may help relieve the host system of i/o pressure. Per this example <https://github.com/phpredis/phpredis#php-session-handler>, the following configuration changes are needed: session.save_handler = redis session.save_path = "tcp://127.0.0.1:6379?persistent=1" This can be further improved by eliminating the TCP/IP overhead when using unix sockets directly: session.save_path = "unix:///var/run/redis/redis.sock?persistent=1" With regards to #24 <#24>, msgpack could be used as a session serialization format: session.serialization_handler = msgpack ⚠️ Changing the serialization format will require clearing *all* sessions! On a related note it may be worth investigating if the I/O scheduler on the host is adjusted correctly. By default, Linux is using the cfq scheduler which is intended for interactive tasks. Server and virtualized environments may profit from deadline (recommended for Amazon, btw) or even noop. The default is controlled by the elevator kernel parameter. Check the settings for existing devices with cat $(find /sys/devices/ -name scheduler). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAz97AjIYuAt8m-ThVGrmyQzzfM44kfMks5rfFmmgaJpZM4MI0dJ> .

[DaSourcerer]

Ah, didn't see that this class is in actual usage. Anyhow, is there a particular reason for keeping the sessions in Cassandra? FWIW, that is supposed to be volatile data.

[markharding]

I would disagree that sessions are volatile data for the server side. If a server had to be flushed then we'd log all of our users out and forget their sessions... not helpful! The sessions on cassandra have a ttl that matches the session so they do get purged when they cease to exist.

Cassandra is truly masterless, if one node dies the other 2 stay up and have that data.

We use Redis as a cache and we frequently clear it and make use for hot items, using redis as a session store would mean we'd need another redis system to be running that has disk storage. I'm certainly open to doing something like that in the future, but it would require a pretty substantial Redis cluster of its own to work well.

[DaSourcerer]

Let me put it like this: You cannot assert the presence of a running session, can you? If one does not exist (or an existing one has been lost), one can easily be created. As sessions introduce state into the HTTP stack, logging the user in may be required. Granted, that is a bit of a nuisance, but also far from a desaster.

What I want to get at here is, I see session data at about the same data safety level than cache content. Therefore I see no issue saving session to disk only every n minutes or (depending on the application in question) hold them in memory entirely. That being said and given that random logouts on Minds are not unheard of, I would argue that a redis cluster is not strictly necessary.

Either way, I'm not going to argue any further here. I thought this were a cheap win, but my premise was wrong. Are you going to look into that I/O scheduler thing?

[markharding]

At the client level I would agree they are disposable, but the server must always be able to detect a 'user' being there if they can show us their identity. Sessions are really important and can not be treated like caching data. Image if there was brief power outage of the session data and it wasn't hard stored; everyone would be logged out and would have to log back in again. This would have a massive impact on user engagement, our DAU, MAU and general user retention.

[markharding]

The reason I mentioned needing another cluster was that the cache buffers do purge what is infrequently accessed, and when they do get full they start to throw things out, so we couldn't use sessions here as users would be thrown off repeatably without any warning.