Session storage has poor performance for hundreds of sessions
If an application contains hundreds of simultaneous sessions, the garbage collection mechanism performs poorly which can eventually result in an unresponsive application.
The root cause for this is the way session entries are retrieved from the cache (in order to check if they need to be removed): in its current implementation, entries with meta information and those acting as storage entries reside in the same cache. Therefore, in order to iterate over the meta entries only, Flow needs to fetch cache entries by tag. Most cache backends will not be able to deliver cache entries by tags with a reasonable speed, thus the complexity for this operation is quite high.
The solution would be to split up caches into a meta cache and a storage cache. Given this, the session garbage collector would be able to iterate over all entries of the meta cache without having to use the find-by-tag mechanism.