Add OPCache to Site Health

[oglekler]

Add OPCache to Site Health > Info > Server.

There is a lot of information about OPCache that can be viewed and possibly not all this information is needed at the first glance, but it will be good to have basic checks if OPCache and OPCache CLI are enabled with a link for further information.

[westonruter]

If opcache isn't enabled then this should also get flagged in a Site Health test too, right? So perhaps the scope here should be to add a test as well as to add the site health info.

[johnbillion]

I support this idea.

Pedantry: This should be an "Opcode cache" health check, OPcache is one implementation of a PHP opcode cache, although in reality all the other opcode cache engines such as APC and eAccelerator were discontinued a decade or more ago.

This PR adds OPCache information to the Site Health Info page so administrators can see how their PHP OPcache is performing.

The code checks if OPcache is available using extension_loaded('opcache'), then gets detailed status using opcache_get_status(). It displays both user-friendly formatted values and debug information for copying to clipboard. All text is properly internationalized and follows WordPress coding standards.

Trac ticket: https://core.trac.wordpress.org/ticket/63697

[rollybueno]

Since this is accepted to Future Release, I've submitted initial patch that can be extended as the ticket progresses.

First it will check for OPCache extension availability, then if loaded, it will use opcache_get_status() to get the following information: used_memory + free_memory = OPcache memory usage, opcache_hit_rate, num_cached_scripts and num_cached_keys. These can be updated once we decided what information we need to display here.

I take these keys from ​https://www.php.net/manual/en/function.opcache-get-status.php response, but I have not fully tested yet. Only this information is available so far, in my end:

If using extension_loaded('opcache'), the result is always false even if it's set to 1. The only time it works is if I use extension_loaded('Zend OPcache'). It's giving mixed results so I'm not sure which one should be more reliable as this could go down per hosting choices.

The question is, should we do a more robust approach by using function_exists( 'opcache_get_status' ) instead and ditch extension_loaded()? This will sacrifice the Is the OPcache extension available? info though.

Hey @westonruter - if you can give advice/opinion, that would be great. Thanks in advance..

I haven't done much with Opcode Cache internals, so I don't have a lot to add. But it seems like using function_exists( 'opcache_get_status' ) is best. The specific extension which enables Opcode Cache would be nice to have as additional information, but now it would most likely always be "Zend OPcache". I'm guessing you'd have to have a list of possible such extensions in an array of strings to test for all of them to see if they are available. So I think there would be two entries:

• Is Opcode Cache enabled?
• Which Opcode Cache extension is being used?

I think this also needs a Site Health test. A site without Opcode Cache should be flagged to users as a performance problem.

[rollybueno]

Ready for testing..

Disabled:

Enabled:

[ugyensupport]

Add OPCache to Site Health

Description

Add OPCache to Site Health > Info > Server.

There is a lot of information about OPCache that can be viewed and possibly not all this information is needed at the first glance, but it will be good to have basic checks if OPCache and OPCache CLI are enabled with a link for further information.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9260/files

Environment

• WordPress: 6.8.2
• PHP: 8.3.14
• Server: Apache/2.4.62 (Unix) mod_wsgi/5.0.1 Python/3.12 mod_fastcgi/mod_fastcgi-SNAP-0910052141 OpenSSL/1.1.1w
• Database: mysqli (Server: 5.7.44 / Client: mysqlnd 8.3.14)
• Browser: Chrome 138.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Health Check & Troubleshooting 1.7.1
  • Test Reports 1.2.0
  • WordPress Beta Tester 3.6.4

Actual Results

1. ✅ Issue resolved with ​https://github.com/WordPress/wordpress-develop/pull/9260/files

Additional Notes

Before:

After:

[abcd95]

I’ve gone through reproducing the issue and then tested the patch from ​PR 9260 with multiple configurations (OPcache enabled/disabled for both web and CLI). The Site Health Info panel displays the opcode cache status and details, and the Site Health Status test behaves as intended, flagging when no opcode cache is active.

Since the ticket already includes a thorough bug testing report with before/after screenshots, and the results match the expected behavior, I’ll proceed to remove the needs-testing label.

​Screenshot of the site health screen when the OPcache is not enabled

[shailu25]

Test Report

This Report Validates that the indicated patch addresses the issue.✅

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/9260

Environment:

WordPress - 6.9-alpha-20250806.023428
OS - Windows
Browser - Chrome
Theme: Twenty Twenty-Five
PHP - 7.4.31
Active Plugin - None

Actual Results:

• Issue Resolved with Patch ✅ (OPcache has been added to Site Health.)

Before: ​https://prnt.sc/ef48OBZHghem
After: ​https://prnt.sc/irT3bduK_X28

[rollybueno]

Adding back the needs-testing tag for testing the feedback on ​https://github.com/WordPress/wordpress-develop/pull/9260#pullrequestreview-3111365991

It basically showing a generic error when using silence call due to possible false response if opcache.restrict_api is set, as per ​https://www.php.net/manual/en/function.opcache-get-status.php#refsect1-function.opcache-get-status-errors.

[westonruter]

@SergeyBiryukov will review and commit

[wildworks]

Since the 6.9 Beta1 release is coming soon, let's punt this ticket to 7.0.

@SergeyBiryukov will review and commit

If you can commit before Beta1, feel free to change the milestone back to 6.9.

[ozgursar]

Test Report

Description

This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9260

Environment

• WordPress: 7.0-alpha-61215-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 143.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Actual Results

✅ Issue resolved with patch. (OPcache has been added to Site Health.)

Screenshots

Before	After

Additional Notes

I couldn't find a way to test against the issue that @rollybueno has mentioned using the WordPress development environment running on Docker Desktop.

• It basically showing a generic error when using silence call due to possible false response if opcache.restrict_api is set, as per ​https://www.php.net/manual/en/function.opcache-get-status.php#refsect1-function.opcache-get-status-errors.

[noruzzaman]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9260

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.29
• Server: nginx/1.29.3
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 143.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.3
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Actual Results

1. ✅ Issue resolved with patch.

Screenshots

Before	After

@rollybueno Hello! Are you intending to follow up on this?

@rollybueno Hello! Are you intending to follow up on this?

Hey @westonruter - gonna look at this today

Yeah, the test passed with re-running and then another one failed for External HTTP, but that's just normal flakiness.

[westonruter]

Taking over review assignment since I've been reviewing the PR.

@oglekler Since you opened this ticket, are you satisfied with the implementation? I was intending to commit soon, even later today.

Site Health test when opcache_get_status() exists and Opcode is enabled, which appears among the passed tests:

Site Health test when function is not available, which appears among the recommended improvements:

This makes my Query Monitor add-on use less. ​https://github.com/szepeviktor/qm-opcache-status

These are two critical measurements

• opcache.memory_consumption
• opcache.interned_strings_buffer

@szepeviktor So you're saying these are missing from the data exposed in this PR?

I mean is the exposed data enough to determine the (new) value of these two directives?

@szepeviktor you tell me 😄

one image for you

@szepeviktor So you're talking about these keys from opcache_get_status() as seen in the ​docs example%20example):

  'opcache_enabled' => bool(true)
  'cache_full' => bool(false)
  'restart_pending' => bool(false)
  'restart_in_progress' => bool(false)
  'memory_usage' => array(4) {
    'used_memory' => int(9167936)
    'free_memory' => int(125049792)
    'wasted_memory' => int(0)
    'current_wasted_percentage' => double(0)
  }
  'interned_strings_usage' => array(4) {
    'buffer_size' => int(8388608)
    'used_memory' => int(2593616)
    'free_memory' => int(5794992)
    'number_of_strings' => int(10358)
  }

That said, what about the remaining keys?

  'opcache_statistics' => array(13) {
    'num_cached_scripts' => int(0)
    'num_cached_keys' => int(0)
    'max_cached_keys' => int(16229)
    'hits' => int(0)
    'start_time' => int(1733310010)
    'last_restart_time' => int(0)
    'oom_restarts' => int(0)
    'hash_restarts' => int(0)
    'manual_restarts' => int(0)
    'misses' => int(0)
    'blacklist_misses' => int(0)
    'blacklist_miss_ratio' => double(0)
    'opcache_hit_rate' => double(0)
  }
  'scripts' => array(0) {}
  'jit' => array(7) {
    'enabled' => bool(false)
    'on' => bool(false)
    'kind' => int(5)
    'opt_level' => int(4)
    'opt_flags' => int(6)
    'buffer_size' => int(0)
    'buffer_free' => int(0)
  }

That said, what about the remaining keys?

They you also appear, but they are not critical.

@szepeviktor ok, with a282d58790c0daa5bc5ee0f6941447bfe40abd50:

opcode_cache: true
opcode_cache_memory_usage: 66074360 of 80652768
opcode_cache_interned_strings_usage: 100% of 8388608 (8 free)
opcode_cache_hit_rate: 99.625374557526
opcode_cache_full: false

Does this now capture all useful information in your opinion?

Yes, thank you.

[westonruter]

In 61612:

Site Health: Add test and debug data for Opcode Cache.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/9260

Props rollybueno, westonruter, swissspidy, peterwilsoncc, szepeviktor, ozgursar, oglekler, johnbillion, ugyensupport, abcd95, shailu25, noruzzaman.
Fixes #63697.

[westonruter]

Follow-up: #64854