Add memcached to frontend machines #5517
Conversation
This adds memcached to the frontend machines. I've copied the config from the other machines with memcached (whitehall, mapit, backend nodes). We'll use this mainly to cache HTTP responses, first from slimmer and hopefully later from gds-api-adapters.
|
How did you arrive at 12%? It looks about right based on frontend machines in production right now (and the hope that this will reduce memory bloat anyway) but it'd be good to have the number documented |
|
As noted, the config was copied from the existing configs. All the nodes are set at 12%. I'll try to find out why. |
|
The history of the 12%:
|
|
#wearethe12percent. Fine by me but probably needs a review from an infrastructure person first |
|
After some googling, I found that the docs in the puppet module that was originally used (saz/memcached) uses 12% as an example: https://github.com/saz/puppet-memcached#use-12-of-available-memory. Perhaps the source? |
|
Can this caching be done with Redis instead of memcached? |
|
Technically yes, but Redis would have to be configured to do LRU based eviction, which it isn't by default. This would also mean we couldn't use the same Redis instances as we currently use, as they can't be configured for LRU eviction. |
|
Had a quick chat with @stephenharker about this. One important consideration is if we can still run applications on Heroku/PaaS without a configured memcached. I'm closing this so it can thought about some more. It doesn't block alphagov/slimmer#183, because apps could be configured to use |
This adds memcached to the frontend machines. I've copied the config from the other machines with memcached (whitehall, mapit, backend nodes).
We'll use this mainly to cache HTTP responses, first from slimmer (alphagov/slimmer#184) and hopefully later from gds-api-adapters.
cc @boffbowsh
https://trello.com/c/D9HmkJwI