"Warm Up Cache" on Deployment

Warm Up Cache on deployment

I have set integration tests that confirm all of the main areas of the site are available (a few hundred pages in total). They don't do anything that changes data - just pull back the pages and forms.

I don't currently run them when I deploy my production instance, but now you mention it - it may actually be a good idea.

Another alternative would be to pull every page that appears in your sitemap (if you have one, which you probably should). It should be really easy to write a gem / rake script that does that.

Symfony warmup cache before deploying?

Depending on your deployment method you can pre warmup. Or have a look at ConsoleBundle that gives you a web ui for the console. Don't forget to protect it!

Doctrine metadata cache during atomic deployments

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.

Should I clear/warm cache after doctrine migrations?

Migrations are responsible for persistence layer only. It has nothing to do with EntityProxies, it only makes Database in sync with Model - that's all.

In production, during deployment, you probably run git pull and composer install, which clears the cache, so migrations shoud run just after that.

Reason - after composer install your new code and Model itself is ready to use new fields/entities, but the Database still falls behind, so migrations keeps it in sync.

Symfony : clear cache and warmup when users are using the website

Works for me, might work for you.

I usually have two versions of my app placed side by side. Only one is connected to web server. If I have to make any changes I update inactive version, clear cache, warmup cache, etc. Then I switch active version in web server.

That way you have as much time as you want for maintenance and switch is unnoticeable for your users.

You can also configure web server to allow inactive version to be available in some internal channel. That way, after you done what you wanted to change you can peek if everything works as expected(or let testers do their work) before you go public.

How to run a Symfony application on a read-only system, where 'var/cache' can't be written into?

If you configure the system not to use a filesystem based cache, you only need to run php bin/console cache:warmup, on deployment and then deploy all the generated code (including the contents of var/cache) to the execution environment.

From here:

In the prod environment (i.e. when APP_ENV is prod and APP_DEBUG is 0), as long as you run php bin/console cache:warmup, no cache files will need to be written to disk at runtime. The only exception is when using a filesystem-based cache, such as Doctrine's query result cache or Symfony's cache with a filesystem provider configured.

You'll also need to make sure that you are not logging to disk.

Nowadays, since Symfony 4, var/cache is mostly meant to store long term artefacts like compiled container files, compiled translations, and/or Doctrine proxies. Not for temporary cache files.

Following these practices, a well configured application should be able to be deployed on read-only environments.

Symfony2 cache warm up issue

Finally I got the solution, it was because the new S2 version. The shared files was renamed from parameters.ini to parameters.yml

set :shared_files, ["app/config/parameters.yml"]

---

Related Topics