6

I'm using PHP with OPcache. I only git-push to master to deploy my web site in production (not really, it's just after unit tests, but never mind). In php.ini file, OPcache settings are about "time" and "frequency". But I just want to reset cache after git pull on my server.

So I think I just need to call opcache_reset after git-pull on my production server and set opcache.validate_timestamps to 0 (never reset cache)

I did not read anything about that way, so I doubt: I don't know if it's a good practice. Did I miss something? Is there any risk or is it OK?

Thanks a lot!

P.S. : I'm using a PHP framework and composer (composer install is running just after git-pull)

rap-2-h
  • 30,204
  • 37
  • 167
  • 263
  • 1
    Might be interesting reading: https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/ – halfer Jan 18 '15 at 19:44
  • 1
    @halfer Yes interesting reading, thanks :) ! It does not answer to my question but I will keep this in mind. – rap-2-h Jan 19 '15 at 08:32
  • You shouldn't run `composer update` because that will grab software your tests didn't run with. Always run `composer install` when using automated scripts. – Sven Jan 22 '15 at 21:27
  • @Sven I run `composer install` but I wrote `composer update` in my question :/ Thanks, I will edit my post ! – rap-2-h Jan 23 '15 at 09:41

1 Answers1

2

In order to get the greatest benefit from OPCache you should disable opcache.validate_timestamps. If you subsequently call opcache_reset() from a script every time you deploy your code to the server, then your OPCache is cleared once for each new set of files, and the system doesn't waste resources constantly checking the files.

There's a couple of "gotchas", however:

First of all, Make sure that the call to opcache_reset() happens, or else you'll be running the old code. If you have a script to execute your deploy, make sure it fails loudly if this step doesn't execute.

Secondly, depending on exactly how PHP is running (mod_php vs php-fpm), you may need to execute the opcache_reset() function via a request to the browser, not via the command line. For example, the most obvious solution to clear the cache is to have a simple PHP file like the following

<?php

if (php_sapi() != "cli") die("Not accessible from web");
opcache_clear();

and execute that file on each code pull. Depending on the version of PHP and how it's run that may only clear the cache for the command line and not for your running web version.

If clearing from the command line doesn't work, consider creating a similar script and calling it via the web using curl or wget. For example, curl http://example.com/clear_cache.php?secret=abc123. If you create the script to be web accessible, then make sure it checks a secret key to prevent someone from loading up your server by constantly clearing your cache.

Finally, as others have suggested, to make your builds totally repeatable between testing and deployment, consider having the end of the test process create a .zip file of the entire code used for testing, including the libraries pulled down by composer. Rather than git pull on your server, just unzip the file over the code root. I realize that git pull && composer update is easy. However, as others have suggested, if a library gets updated between the time tests were run and the time of deployment, then your code may no longer work as expected.

jwriteclub
  • 1,604
  • 1
  • 17
  • 33
  • Ok thanks! About your last point, it's not a problem for because I do not use `composer update`, I use `composer install` (so no difference between tests and prod, the `composer.lock` is the same) – rap-2-h Jul 23 '16 at 09:30