zabeen
commented
3 months ago Questions
- Document all the places in Atlas when in-memory caching is performed to help decide whether the data should remain on the app cache, or whether it should be moved to a distributed shared cache.
- On this subject: hosting the H.M.D. copy on distributed cache instead of app cache could allow us to validate patient HLA during search initiation and donor HLA during donor import. Currently not doing that to avoid cache warm-up times during horizontal scaling. This is not a performance "win", but catching invalid HLA as early as possible is better UX. Raise new cards if we decide to do this (there might be existing ones in the backlog).
- Are there restrictions as how many open connections we can have from our various apps to the distributed cache?
- This change will need to be assessed for cost.
- At the very least, we want the additional cost of the new Redis for Azure resource to be offset by the money saved on elastic plan CPU time/memory usage/horizontal scaling.
- How can we answer this question? Deploy a spike to UAT-WMDA and run checks there?
Atlas heavily makes use of cached data from its reference data sources - the HMD and MAC stores particularly. Cache warming will be hit a lot when we're scaling on an elastic plan.
This idea is to investigate the feasibility of Redis as a shared cache solution, to allow rapid scaling without the cold start impact of cache warming.
Redis would need to be at least as quick as in memory caches to use when running searches, and would also need to be demonstrably reducing the cold start time of Atlas. Additionally any impact on the cost of running Atlas should be considered, and any known organisations with production instances of Atlas running (i.e. Anthony Nolan, WMDA) must be consulted on any change to running cost.