Memcached Question posted in
A decent usage manual can be found here.

Memcached – Doctrine metadata cache during atomic deployments

How do you handle Doctrine’s metadata cache during application deployment?

We use the atomic deployment strategy for our applications. Until now we used to use the default file caching method which works very well. We would like however to switch to an in-memory cache like Redis/Memcached for performance reasons.

Should we use some kind of cache ID prefix for each release? For instance when a new version of the software is released, the deployment script warms up the app and fills the cache with new schema metadata. Should the deploy fail we do the rollback and the metadata cache would be still valid.

What’s the best method to approach this? I’d like to avoid CPU spikes when the first requests come in and there’s no metadata cache yet.

Tags:

2

Answers


  1. 0

    This is how we do it:

    1) We deploy the app to the target server
    (We use the AWS hosting. So we spin up a new instance, deploy the app, when done we change the main server to the new, prepaired one)

    2) We clean caches in this order:

    php bin/console doctrine:cache:clear-metadata --env=prod
php bin/console doctrine:cache:clear-query --env=prod
php bin/console cache:clear --env=prod

    3) Bring prepaired instance to production (as a LB-upstream)

    If something should be rolled back we prepair the rollback on a new instance (not reachable by public views) and clear the caches again. If everything went fine we bring this new server to the loadbalancer upstreams.

    We only work with cache keys for categorizing, also cache pools we use to group things. We got a redis for dev, one for staging one for production, so that in case we can “FLUSHALL” in each redis-cli and it does not affect other environments.

    Hope it helps!

    Login or Signup to reply.
  2. 0

    Should we use some kind of cache ID prefix for each release?

    Yeah that’s an approach I’ve used several times. Once the code is on the server, vendors are installed, just prior to making the switch, warm the cache with a unique prefix. A rollback will use the cache that was in use prior to the deploy.

    Setting the prefix can be tricky and depends on your environment. Your application might read from some version file that contains nothing but a unique version identifier. Your deployment might create this. One option is to use the git hash of the current HEAD (or a tag if you’re tagging releases). Avoid relying on a developer to manually bump the version.

    Keep in mind this approach requires some extra care be taken to not fill up your chosen cache solution’s storage. Some techniques to consider:

    • Cache entries should have a lifetime (E.g. with Redis, ensure there is an expiry on the entries)
    • When an old release is removed from the server, its cache should also be purged.
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search