Pain Point: Maas UI and CLI is S L O W, esp when you get to the scale that we have (2200+ machines in maas and climbing daily)
Proposed Solution: Caching layer, my preferred one being memcached (low resource use, single binary, single config file), volatile cache that scales horizontally extremely well. though any distributed cache should work fine (the operative term being DISTRIBUTED which memcached and it’s clients handle seamlessly)
Maas Stores everything in the DB
Good, makes the region controllers stateless
Bad, becomes the point of contention, especially if DB queries are expensive (they are) or schema is non-ideal (I cannot say for sure)
Most frameworks already havd caching capability, but the general workflow is the following:
Read/select requests:
- Check cache, if it’s there, return it, and you’re done
- If cache missed, fetch it from the DB , insert it into the cache and return it, you’re done
Write’s/updates
- Update DB, update (or invalidate) cached entry
Deletes:
- Delete from DB, invalidate cache entry
Many user operations in MaaS via the gui or CLI involve fetching the same data over again multiple times, a cache eliminates all subsequent requests other than the first one until the TTL of the cached entry expires… Everyone wins, maas gets (a LOT) faster, users are happier…