Change #1315940 had a related patch set uploaded (by Kamila Součková; author: Kamila Součková):

[operations/puppet@production] aptrepo: add php85 component

https://gerrit.wikimedia.org/r/1315940

Change #1315948 had a related patch set uploaded (by Kamila Součková; author: Kamila Součková):

[operations/puppet@production] package_builder: add pbuilder hook for component/php85

https://gerrit.wikimedia.org/r/1315948

php-apcu 5.1.24 → 5.1.28

It's worth reading through https://github.com/krakjoe/apcu/releases as there have been more changes than in prior years.

apc.entries_hint now defaults to 512 entries per 1MB of shared memory. Previously the default was 4096, independent of shm_size. This could lead to a large number of hash collisions if shm_size was increased without also increasing entries_hint.

https://www.php.net/manual/en/apcu.configuration.php:

apc.entries_hint Default: 512 * apc.shm_size. Previously: 4096.

Sounds like that is us, given that we raise shm_size from the default but not entries_hint, per Codeseach: apc INI (no matches for entries_hint) and Codesearch: apcu YAML (2048M for mw-web, and 4096M for mw-jobrunner).

Per Grafana: MediaWiki on k8s, we usually have 250K entries per pod on mw-web:

Perhaps this explains why encounter so much read lock contention with php-apcu (T293630 etc) and thus why we had to make our pods so small and duplicate a lot of opcache/apcu memory. It could also explain why other big sites running PHP perhaps haven't prioritised the issue upstream either, if this avoids most of it.

Anyway, this is a good thing and might not require changes. But it may be worth exploring during the benchmarks this time around between php83 and php85 (akin to T280497#7463143). And if we see a considerable improvement in concurrent before latency suffers, we could add a variant of php83 that raises apc.entries_hint to 1 million (512*2048) to see if that gives it similar behavior. That would help attribute the gain to a specific cause, and I could then share that with upstream.

Change #1315940 merged by Kamila Součková:

[operations/puppet@production] aptrepo: add php85 component

https://gerrit.wikimedia.org/r/1315940

Change #1315948 merged by Kamila Součková:

[operations/puppet@production] package_builder: add pbuilder hook for component/php85

https://gerrit.wikimedia.org/r/1315948

Mentioned in SAL (#wikimedia-operations) [2026-08-04T15:44:48Z] <Raine> add php8.5 packages to component/php85 - T432983

Unfortunately I can't use the Wikimedia php85 packages as-is for CI yet, as component/php85 in bookworm-wikimedia is missing:

• php-common (php-defaults) 2:95 or newer — php8.5-common needs it, and the newest available is 2:94+wmf12u1, so nothing installs.
• PHP 8.5 builds of the extensions the CI images use: apcu, excimer, luasandbox, memcached, pcov, redis, uuid, wikidiff2, xdebug, yaml.

Also our builds claim to be PHP 8.5.8; per https://www.php.net/archive/2026.php#2026-07-30-2 we probably want to be 8.5.9.

@Jdforrester-WMF - Indeed, populating component/php85 is a work in progress as the builds progress. Specifically, we need to fill the component incrementally in order to satisfy build-depends for the extension packages (and things like php-defaults). @Raine will give a heads-up here when it's actually ready to be used.

Ah, and thanks for catching the 8.5.9 - I think there was just a race between starting work last week and when .9 was released. That will be updated before the go-ahead to use the component.

In T432983#12189685, @Scott_French wrote:

@Jdforrester-WMF - Indeed, populating component/php85 is a work in progress as the builds progress. Specifically, we need to fill the component incrementally in order to satisfy build-depends for the extension packages (and things like php-defaults). @Raine will give a heads-up here when it's actually ready to be used.

Aha, cool, will wait then. :-)

Ah, and thanks for catching the 8.5.9 - I think there was just a race between starting work last week and when .9 was released. That will be updated before the go-ahead to use the component.

Ack.

In T432983#12189692, @Jdforrester-WMF wrote:

In T432983#12189685, @Scott_French wrote:

@Jdforrester-WMF - Indeed, populating component/php85 is a work in progress as the builds progress. Specifically, we need to fill the component incrementally in order to satisfy build-depends for the extension packages (and things like php-defaults). @Raine will give a heads-up here when it's actually ready to be used.

Aha, cool, will wait then. :-)

Yup, I should be done sometime next week if nothing goes horribly wrong.

Ah, and thanks for catching the 8.5.9 - I think there was just a race between starting work last week and when .9 was released. That will be updated before the go-ahead to use the component.

Ack.

Thanks, indeed, 8.5.9 came out just after I made my list :D Rebuilt and task description updated.

Note about php-wmerrors: it needed a patch for PHP 8.5 as smart_string moved:

--- php-wmerrors-2.0.0.orig/php_wmerrors.h
+++ php-wmerrors-2.0.0/php_wmerrors.h
@@ -17,7 +17,7 @@ extern zend_module_entry wmerrors_module
 #include "TSRM.h"
 #endif
 
-#include "ext/standard/php_smart_string_public.h"
+#include "zend_string.h"
 
 PHP_MINIT_FUNCTION(wmerrors);
 PHP_MSHUTDOWN_FUNCTION(wmerrors);
--- a/wmerrors.c
+++ b/wmerrors.c
@@ -12,7 +12,7 @@
 #include "ext/standard/php_standard.h"
 #include "SAPI.h" /* for sapi_module */
 #include "ext/date/php_date.h" /* for php_format_date */
-#include "ext/standard/php_smart_string.h" /* for smart_string */
+#include "zend_string.h" /* for smart_string */
 #include "Zend/zend_builtin_functions.h" /* for zend_fetch_debug_backtrace */
 #include "Zend/zend_exceptions.h" /* for zend_ce_exception */

This should probably be handled upstream, but I'm not sure by whom, as https://www.mediawiki.org/wiki/Developers/Maintainers lists the steward as Unassigned.

Never mind the above, it's fixed in https://gerrit.wikimedia.org/r/c/mediawiki/php/wmerrors/+/1216752 . However, it is not in upstream yet. I'll work on that.

In T432983#12212932, @Raine wrote:

Never mind the above, it's fixed in https://gerrit.wikimedia.org/r/c/mediawiki/php/wmerrors/+/1216752 . However, it is not in upstream yet. I'll work on that.

Thanks @taavi for updating debian upstream <3

With that, all packages are built and in the php85 component, but not tested yet.

All packages are present and install, and at least <?php echo "hello, world"; works.

In T432983#12216338, @Raine wrote:

All packages are present and install, and at least <?php echo "hello, world"; works.

I've migrated CI to use the WMF packages, and tests all seem to pass. Let's consider this Done. :-)

In T432983#12161093, @Krinkle wrote:

php-apcu 5.1.24 → 5.1.28

It's worth reading through https://github.com/krakjoe/apcu/releases as there have been more changes than in prior years.

apc.entries_hint now defaults to 512 entries per 1MB of shared memory. Previously the default was 4096, independent of shm_size. This could lead to a large number of hash collisions if shm_size was increased without also increasing entries_hint.

https://www.php.net/manual/en/apcu.configuration.php:

apc.entries_hint Default: 512 * apc.shm_size. Previously: 4096.

Sounds like that is us, given that we raise shm_size from the default but not entries_hint, per Codeseach: apc INI (no matches for entries_hint) and Codesearch: apcu YAML (2048M for mw-web, and 4096M for mw-jobrunner).

Per Grafana: MediaWiki on k8s, we usually have 250K entries per pod on mw-web:

Perhaps this explains why encounter so much read lock contention with php-apcu (T293630 etc) and thus why we had to make our pods so small and duplicate a lot of opcache/apcu memory. It could also explain why other big sites running PHP perhaps haven't prioritised the issue upstream either, if this avoids most of it.

Anyway, this is a good thing and might not require changes. But it may be worth exploring during the benchmarks this time around between php83 and php85 (akin to T280497#7463143). And if we see a considerable improvement in concurrent before latency suffers, we could add a variant of php83 that raises apc.entries_hint to 1 million (512*2048) to see if that gives it similar behavior. That would help attribute the gain to a specific cause, and I could then share that with upstream.

These are great observations, thank you. I have opened T435072 to track this separately.