I've actually had it running like this since my post and I haven't noticed any issues. The amount of keys in redis seems identical and I did observe the ttl changes upon session access.

Sadly it didn't help with my nextcloud talk issue, but it didn't introduce new problems.

Depending on redis server config, sessions can be evicted due to memory pressure also ( but maybe this isn't a factor with a standard nextcloud configuration )
Also, I am pretty sure gc is a noop with redis session handler, so I think your issue might be elsewhere ( i haven't checked for a while admittedly )

True, memory pressure eviction of keys would be a problem either way, wouldn't it? I guess having a separate redis for sessions and caching is the only way to guarantee no sessions are evicted. Or is there a way in redis that certain keys should remain under pressure?

Gc being a noop would be great to know for certain.

I guess having a separate redis for sessions and caching is the only way to guarantee no sessions are evicted

This is generally what I would recommend regardless because you can tune for memory only ephemeral keys for caching and then have a different cluster with no eviction ( and maybe storage backed resilience depending on use case ) for persistent data. ( eviction policies are a global setting )

Redis processes themselves are actually pretty lightweight, so there is nothing really stopping you running multiple instances even on the same machines.

@michael-grunder I've just looked around in the redis_session.c and I stumpled over redis.session.early_refresh in there. Enabling that would mean that the TTL is updated both when opening the session and when closing it, right? PS_WRITE_FUNC always uses SETEX and PS_READ_FUNC uses GETEX if I enable that option

I added that feature a couple of years ago, along with lazy writes. It might have an impact if you are holding connections open for a long time, however if you are, you might find that expires happen at some point for the duration of the script runtime regardless.

In these cases you should implement a heartbeat function that periodically updates the session ttl ( either via an ajax ping, or within your active request by sending your own EXPIRE for the session key to redis ( you might find php complains if you try to write_close and the start tbe session again, but maybe it can work too )

( you will have to find what works well for your setup here as there are a lot of variables that effect how sessions at handled )

yeah I agree with the heartbeat thing, but this is completely out of my control as the issue here is with nextcloud (spreed specifcally).