You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: