The behaviour of these functions is affected by settings in php.ini .

For further details and definitions of the PHP_INI_* modes, see the Where a configuration setting may be set

Here's a short explanation of the configuration directives.

Enables the opcode cache. When disabled, code is not optimised or cached. The setting opcache.enable can not be enabled at runtime through ini_set(), it can only be disabled. Trying to enable it at in a script will generate a warning.

Enables the opcode cache for the CLI version of PHP.

The size of the shared memory storage used by OPcache, in megabytes. The minimum permissible value is "8" , which is enforced if a smaller value is set.

The amount of memory used to store interned strings, in megabytes. This configuration directive is ignored in PHP < 5.3.0.

The maximum number of keys (and therefore scripts) in the OPcache hash table. The actual value used will be the first number in the set of prime numbers { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987, 262237, 524521, 1048793 } that is greater than or equal to the configured value. The minimum value is 200. The maximum value is 100000 in PHP < 5.5.6, and 1000000 in later versions. Values outside of this range are clamped to the permissible range.

The maximum percentage of wasted memory that is allowed before a restart is scheduled. The maximum permissible value is "50" , which is enforced if a larger value is set.

If enabled, OPcache appends the current working directory to the script key, thereby eliminating possible collisions between files with the same base name. Disabling this directive improves performance, but may break existing applications.

If enabled, OPcache will check for updated scripts every opcache.revalidate_freq seconds. When this directive is disabled, you must reset OPcache manually via opcache_reset(), opcache_invalidate() or by restarting the Web server for changes to the filesystem to take effect.

How often to check script timestamps for updates, in seconds. 0 will result in OPcache checking for updates on every request. This configuration directive is ignored if opcache.validate_timestamps is disabled.

If disabled, existing cached files using the same include_path will be reused. Thus, if a file with the same name is elsewhere in the include_path, it won't be found.

If disabled, all documentation comments will be discarded from the opcode cache to reduce the size of the optimised code. Disabling this configuration directive may break applications and frameworks that rely on comment parsing for annotations, including Doctrine, Zend Framework 2 and PHPUnit.

If disabled, documentation comments won't be loaded from the opcode cache even if they exist. This can be used with opcache.save_comments to only load comments for applications that require them.

If enabled, a fast shutdown sequence is used that doesn't free each allocated block, but relies on the Zend Engine memory manager to deallocate the entire set of request variables en masse. This directive has been removed in PHP 7.2.0. A variant of the fast shutdown sequence has been integrated into PHP and will be automatically used if possible.

When enabled, the opcode cache will be checked for whether a file has already been cached when file_exists(), is_file() and is_readable() are called. This may increase performance in applications that check the existence and readability of PHP scripts, but risks returning stale data if opcache.validate_timestamps is disabled.

A bitmask that controls which optimisation passes are executed.

In PHP < 5.3, OPcache stores the places where DECLARE_CLASS opcodes used inheritance; when the file is loaded, OPcache then tries to bind the inherited classes using the current environment. The problem is that while the DECLARE_CLASS opcode may not be needed for the current script, if the script requires that the opcode be defined, it may not run. This configuration directive is ignored in PHP 5.3 and later.

This hack should only be enabled to work around "Cannot redeclare class" errors.

The location of the OPcache blacklist file. A blacklist file is a text file containing the names of files that should not be accelerated, one per line. Wildcards are allowed, and prefixes can also be provided. Lines starting with a semi-colon are ignored as comments. A simple blacklist file might look as follows: ; Matches a specific file. /var/www/broken.php ; A prefix that matches all files starting with x. /var/www/x ; A wildcard match. /var/www/*-broken.php

The maximum file size that will be cached, in bytes. If this is 0 , all files will be cached.

If non-zero, OPcache will verify the cache checksum every N requests, where N is the value of this configuration directive. This should only be enabled when debugging, as it will impair performance.

The length of time to wait for a scheduled restart to begin if the cache isn't active, in seconds. If the timeout is hit, then OPcache assumes that something is wrong and will kill the processes holding locks on the cache to permit a restart. If opcache.log_verbosity_level is set to 2 or above, a warning will be recorded in the error log when this occurs.

The error log for OPcache errors. An empty string is treated the same as stderr , and will result in logs being sent to standard error (which will be the Web server error log in most cases).

The log verbosity level. By default, only fatal errors (level 0) and errors (level 1) are logged. Other levels available are warnings (level 2), information messages (level 3) and debug messages (level 4).

The preferred memory model for OPcache to use. If left empty, OPcache will choose the most appropriate model, which is the correct behaviour in virtually all cases. Possible values include mmap , shm , posix and win32 .

Protects shared memory from unexpected writes while executing scripts. This is useful for internal debugging only.

The base used for shared memory segments on Windows. All PHP processes have to map shared memory into the same address space. Using this directive allows "Unable to reattach to base address" errors to be fixed.

Allows calling OPcache API functions only from PHP scripts which path is started from specified string. The default "" means no restriction.

Prevents caching files that are less than this number of seconds old. It protects from caching of incompletely updated files. In case all file updates on your site are atomic, you may increase performance by setting it to "0".

Enables or disables copying of PHP code (text segment) into HUGE PAGES. This should improve performance, but requires appropriate OS configuration. Available on Linux as of PHP 7.0.0, and on FreeBSD as of PHP 7.4.0.

Absolute path used to store shared lockfiles (for *nix only)

Produces opcode dumps for debugging different stages of optimizations. 0x10000 will output opcodes as the compiler produced them before any optimization occurs while 0x20000 will output optimized codes.

Enables and sets the second level cache directory. It should improve performance when SHM memory is full, at server restart or SHM reset. The default "" disables file based caching.

Enables or disables opcode caching in shared memory.

Enables or disables checksum validation when script loaded from file cache.

Implies opcache.file_cache_only=1 for a certain process that failed to reattach to the shared memory (for Windows only). Explicitly enabled file cache is required. Caution Disabling this configuration option may prevent processes to start, and is therefore discouraged.

Validates the cached file permissions against the current user.

Prevents name collisions in chroot'ed environments. This should be enabled in all chroot'ed environments to prevent access to files outside the chroot.

Specifies a PHP script that is going to be compiled and executed at server start-up, and which may preload other files, either by includeing them or by using the opcache_compile_file() function. All the entities (e.g. functions and classes) defined in these files will be available to requests out of the box, until the server is shut down. Note: Preloading is not supported on Windows.

Preloading code as root is not allowed for security reasons. This directive facilitates to let the preloading to be run as another user.