36

In the documentation it says "mostly used for debugging" which would lead me think "never enable it unless you've a problem and need to do some debugging," however reading mostly everything that I could find about it says to enable it "opcache.enable_cli 1" but why? I could not find any information concerning this matter, so if anybody knows, why should I enable it if the documentation basically says to keep it on 0?

Machavity
  • 30,841
  • 27
  • 92
  • 100
Jack
  • 653
  • 1
  • 6
  • 14
  • 1
    While the accepted answer http://stackoverflow.com/a/25047263/934195 is correct for PHP 5, there are answers which have relevant details for PHP 7 users like http://stackoverflow.com/a/35880017/934195 – Mark Fox Dec 06 '16 at 23:40

3 Answers3

49

With PHP7 and file-based caching, it can now make sense to enable opcache for CLI. The best possibility would be to have a separate php.ini for CLI with the following configuration:

opcache.enable=1
opcache.enable_cli=1
opcache.file_cache="/tmp/php-file-cache"
opcache.file_cache_only=1
opcache.file_cache_consistency_checks=1

opcache.file_cache_only=1 makes sure that the in-memory opcache is disabled and only files are used, which is what you want for CLI. This should boost execution time by quite a bit.

In the php.ini for FPM, you will want to have the same settings but use opcache.file_cache_only=0, so in-memory opcache is used and the file cache is used as a fallback (which also makes FPM faster, because the file cache reduces warmup time when FPM is restarted or opcache is reset, because the cached files remain).

This way, CLI and FPM share the file cache, and FPM has the in-memory cache as a second primary cache for maximum speed. A great improvement in PHP7! Just make sure to choose a directory for opcache.file_cache that both CLI and FPM can write to, and that the same user does the writing/reading.

UPDATE 2017

I would not recommend to use the file cache with FPM anymore (only use it for CLI), because there is no way to reset the cache when setting opcache.validate_timestamps=0 - the file cache prevents PHP-FPM from recognizing any changes, because opcache_reset() or even a complete PHP-FPM restart does not affect the file cache and there is no equivalent for the file cache, so changed scripts are never noticed. I reported this as a "bug"/"feature request" in March 2016, but this is currently not seen as an issue. Just beware if you use opcache.validate_timestamps=0!

BenMorel
  • 34,448
  • 50
  • 182
  • 322
iquito
  • 2,388
  • 1
  • 18
  • 26
  • If we use `opcache.file_cache_only=0`, what should the value of `opcache.memory_consumption` be, on a 8GB RAM server? – PKHunter Feb 14 '17 at 10:45
  • That depends on how many files will be cached/how many projects are running on the server and also if that server has other duties than to run PHP-FPM. I would recommend to try it first with 500MB - it is quite hard to exceed that. Then check on your usage with a script like https://github.com/rlerdorf/opcache-status , which gives you a nice overview, and adapt the size if necessary. Rather go too large than too small, otherwise opcache will restart too often when the limit is reached. – iquito Feb 14 '17 at 16:13
  • 2
    The usage difference is incredible, before setting up the CLI to use it, I had a script to download emails over IMAP that would sit there at 100% for a few seconds at a time, but now it never hits 30% – Brian Leishman Feb 19 '18 at 20:12
  • @iquito wouldn't just removing the actual cache files with `rm` work? – Danila Vershinin Aug 28 '18 at 05:53
  • @DanielV. Maybe, yet it makes the cache system quite complicated and in my opinion error prone. You would need to delete all cache files and then call `opcache_reset()`. Race conditions can easily occur: between the `rm` and `opcache_reset()` new files could have already been created. Especially when you deploy an application some files will have changed and there is no "atomic" way to delete the file cache and the opcache in sync. PHP-FPM might also have issues if it tries to read a file that has just been deleted by `rm`. – iquito Aug 29 '18 at 12:04
  • Can you link to your bug report please? – Rob Olmos Jan 14 '19 at 05:40
  • I added the links to both my bug report and my feature request. – iquito Jan 14 '19 at 22:09
  • if you get `Fatal Error opcache.file_cache_only is set without a proper setting of opcache.file_cache`, try `opcache.file_cache="/tmp/"` – Jerem Nov 05 '20 at 14:51
  • 2
    @iquito I found that things aren't that scary as they seemed. It is quite possible to make for atomic deployment, I've written it [here](https://www.getpagespeed.com/server-setup/php/zend-opcache#file_cache_cleaning). Essentially either `mv` or `rm` the file-based OPCache directory *itself*, not its content during deployment. This would make it unusable to PHP process (because it does not like to create it!). Thus when the directory is missing you are safe to run `opcache_reset()`, and then recreate the directory in place. There would be no race conditions. – Danila Vershinin May 26 '21 at 22:55
38

Leave it off. It's primarily there for use while debugging issues with OPcache itself.

The opcache.enable_cli option enables PHP OPcache when running PHP scripts from the command line (using the php command). However, keep in mind that for PHP 5.x the OPcache extension works by storing cached opcodes in the memory of the current process. This is only useful when the process that's running PHP is going to be handling multiple requests that can reuse these opcodes, like in a web server or under FastCGI. For a process like the PHP CLI, which runs one "request" and exits, it just wastes memory and time.

Mark Fox
  • 8,694
  • 9
  • 53
  • 75
  • But I am also using FastCGI cache together with Nginx. Should I still leave it off? – Jack Jul 31 '14 at 00:48
  • Leave it off. It doesn't have any effect on FastCGI at all. –  Jul 31 '14 at 04:42
  • I expect this to be useful in a unit-test scenario though. However, I did not experience any improvement. – yhager Feb 10 '15 at 22:10
  • @Jack it is possible to just execute code in the opcache from the cli - google cgi-fcgi – ck_ Aug 06 '15 at 13:58
  • 11
    This answer is not up-to-date anymore with the file-based cache that opcache now provides. – Florian Margaine Feb 09 '16 at 22:59
  • @FlorianMargaine Fascinating. I haven't heard of that, and I don't see anything about it in the documentation - can you provide a reference? –  Feb 10 '16 at 00:41
  • 3
    @duskwuff: I just added an answer referring to this new functionality in PHP7, where it makes sense to enable enable_cli together with the new file cache options. – iquito Mar 08 '16 at 23:25
  • 2
    @duskwuff: enable_cli=1 has huge impacts with some libraries (e.g. Symfony/Doctrine) which store caches in php files, and include these files multiple times during the execution of the script. I've reduced my CPU usage by 20-40% with enable_cli=1. – Arnaud Le Blanc Oct 27 '16 at 11:59
2

As per PHP docs:

opcache.enable_cli boolean enables the opcode cache for the CLI version of PHP. This is mostly useful for testing and debugging.

Therefore it should be disabled unless you're really need this.

This can be useful when you've some long-term migration process running from the command-line (personally I've tested OPcache v7.0.3 for CLI by running some extensive migration script and I didn't see much performance improvements).

kenorb
  • 155,785
  • 88
  • 678
  • 743