#3261 Redesign session handling
Opened 10 months ago by tkopecek. Modified 10 months ago

Session handling is still the painpoint of bigger deployments. Table can easily grow to gigabytes even with few thousands active sessions and needs to be cleaned separately by koji-sweep-db as autovacuum can't handle it due to extensive locking. Also these locks have very limited usecases.

Let's start discussion about how we can improve/replace current design. We basicall have to ensure:
1) callnum handling
2) exclusive sessions

Quick idea is that callnum handling is secondary issue here as when we would be able to reimplement exclusive sessions, callnum will probably be automatic side-effect of this. Very rough idea is to put locking out of the db. Crude variant would be file locks on hub but it is taking out possibility of horizontal scaling. So, some server-like soulution would be needed. Most simple variant achieving this is separate memcached(-like) server (don't use anything more complicated like redis, etc. as we need just this very mechanism) with atomic operations. Running another service is not nice, so if we can do that without it (some other PG solution or better algorithm) it would be much better. I'm not even sure if deployment complexity of another server is worth the gain.


Login to comment on this ticket.

Metadata