-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Follow-up to #41
For performance reasons it would be good to allow a more robust Redis session manager. Two ideas for this are:
-
Usage of a connection pool
An app with many threads can run into bottle necks with a single Redis connection. This is due to Ruby's GVL and the fact the Redis connection is thread safe. With Ruby's GVL, it ensures only 1 ruby thread is active at a time; but IO does not count towards this. The Redis connection is protected to ensure only 1 thread is actively communicating on it at a time. So what can happen is the Redis connection submits Thread-A's request over IO, which allows Thread-B to run. Thread-B attempts to access the session manager, but becomes blocked as Thread-A's IO hasn't returned or been processed yet.
Usage of a connection pool alleviates this issue as it allows multiple connections to exist side-by-side. However, we need to balance the need of many apps, with many connection pools, having to access a shared Redis instance or cluster.
-
Add an in-memory cache tier
The reason for this is when someone sends multiple requests in-rapid succession (maybe HTTP API calls). We don't want to necessarily hit the network every time when we just checked the validity of the data.