Thanks, @tstarling!

My understanding is that your RequestTimeout change is a performance mitigation for the now-more-expensive manipulation of Excimer timers. Is there anything else that should be monitored as a result of that? (i.e., in addition to segfaults and exceptions more generally)

Excimer 1.2.5-1 packages are now available in /var/cache/pbuilder/result/bullseye-amd64/ on build2001, but have not yet been included in the apt repository.

In contrast to 1.2.3-1 (T389243), this required only minor modifications to debian/control. This is to allow builds with the specific dh-php (5.4) and php-defaults (92) versions we use in component/php81 (there's no functional difference as a result).

Change #1165594 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/docker-images/production-images@master] php8.1: rebuild images to pick up excimer 1.2.5

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

Alright, the remaining steps here are:

• Include the packages in apt.wikimedia.org. From apt1002:

cd /home/swfrench/php/packages/bullseye-amd64/extensions/
sudo -i reprepro -C component/php81 include bullseye-wikimedia $(pwd)/php-excimer_1.2.5-1+wmf11u1_amd64.changes

• Merge https://gerrit.wikimedia.org/r/1165594.
• Build the images as described here. Tip: use --select '*php8.1*' to build only these images.
• Deploy with scap to pick up the new images. Expect this to take 20-30m at a minimum, due to the change in base image.
• Supervise as described in this task.

I may be able to complete this before I disappear on the 3rd (returning the 14th), but in case I can't, I'm writing this out so someone else can pick it up easily.

Note: The changes file for the current excimer package (1.2.3-1) is php-excimer_1.2.3-1+wmf11u1_amd64.changes in that same directory, in the unlikely event we need to revert.

Change #1165594 merged by Effie Mouzeli:

[operations/docker-images/production-images@master] php8.1: rebuild images to pick up excimer 1.2.5

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

Mentioned in SAL (#wikimedia-operations) [2025-07-03T10:26:48Z] <jiji@deploy1003> Started scap sync-world: T397907 - Upgrade Excimer to 1.2.5 in production

Mentioned in SAL (#wikimedia-operations) [2025-07-03T10:43:33Z] <jiji@deploy1003> Locking from deployment [ALL REPOSITORIES]: T397907 - Upgrade Excimer to 1.2.5 in production in progress, blocking deploys

Mentioned in SAL (#wikimedia-operations) [2025-07-03T11:27:49Z] <jiji@deploy1003> Unlocked for deployment [ALL REPOSITORIES]: T397907 - Upgrade Excimer to 1.2.5 in production in progress, blocking deploys (duration: 44m 16s)

Mentioned in SAL (#wikimedia-operations) [2025-07-03T11:30:00Z] <jiji@deploy1003> Started scap sync-world: T397907 - Upgrade Excimer to 1.2.5 in production

Mentioned in SAL (#wikimedia-operations) [2025-07-03T11:35:06Z] <jiji@deploy1003> Finished scap sync-world: T397907 - Upgrade Excimer to 1.2.5 in production (duration: 06m 59s)

In T397907#10961100, @Scott_French wrote:

My understanding is that your RequestTimeout change is a performance mitigation for the now-more-expensive manipulation of Excimer timers. Is there anything else that should be monitored as a result of that? (i.e., in addition to segfaults and exceptions more generally)

I confirmed using the reversed flame graphs that the time attributed to RequestTimeout has decreased.