"今のまま" PHP サーバーを高速化する� PHP 8.6 に向けた�"OPcache Static Cache"�RFC について
PHP Conference 2026 / Go Kudo (@zeriyoshi)
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
1
アジェンダ
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
2
PHP の仕組みについて
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
3
PHP の動作形態と仕組み
PHP は現状、だいたい以下のどれかの方法で動いている。�これらは SAPI (Server-side API) とも呼ばれる (サーバーではなくともそう呼ばれる)
一方で、最近ではちょっと変わった実行方法も増えてきている (これは後述)
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
4
PHP の動作形態と仕組み
PHP は基本的にシェアードナッシング型アーキテクチャで動作している
つまり、リクエストを処理する際に初期化したメモリやリソースなどは static だろうと�リクエスト終了ごとに破棄され、次のリクエストで生成しなおされる
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
5
Request1 End
Zend Engine + Extension
Request1 Start
Free
Zend Engine + Extension
Request1 Working Memory
Free
Request2 Start
Zend Engine + Extension
Free
Request2 End
Zend Engine + Extension
Request2 Working Memory
Free
シェアードナッシング型アーキテクチャのメリット・デメリット
シェアードナッシング型の PHP サーバー
メリット
デメリット
他言語などの通常の Web サーバー
メリット
デメリット
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
6
シェアードナッシングの実例
PHP において、次のコードは何度リクエストを受けても 1 しか返さない
<?php declare(strict_types=1);
final class Foo {
public static int $counter = 0;
}
echo ++Foo::$counter, \PHP_EOL;
// 一生 1 しか返さない
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
7
PHP のキャッシュの現状
現状、 PHP は基本的にシェアードナッシング型アーキテクチャで動作しており�言語機能単体ではリクエストを跨ぐキャッシュを実現する手段がない
よく使われる回避策:
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
8
PHP のキャッシュの現状
今一番筋が良い解決方法は OPcache preload による静的配列のプリローディングか�Swoole と SwooleTable を用いたキャッシュを利用すること
一方で、 “常時実行型 PHP ランタイム” は殆どの場合において既存のコードベースをそのまま移植することは難しい (Larvel なら singleton を scoped に変えるなど対応が必要、 FrankenPHP はリクエスト持ち越しができてもそれは worker ごとなので、結局完全な一つのキャッシュは実現できない�(ただし、実装完了したはずなので次のリリースから使えそう)
何より、シェーアドナッシングアーキテクチャありきで書かれた古いコードベースを常時実行型 PHP に移行するハードルはとてつもなく高い
じゃあ、より速い APCu を作れば良いのでは？
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
9
“colopl_cache” について
もっと速い APCu を、と PHP コードベースの調査を始め、某社社内で作成していた内製�PHP Extension
基本戦略はこうだった:
結果: あんまり意味なかった
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
10
“colopl_cache” について
敗因
じゃあどうしようか...
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
11
“colopl_xcache” について
戦略レベルで考え直し、 “そもそもシリアライズを無くす” を目標にすることに
戦略:
結果: DateTime を含むモデルがめちゃくちゃ速くなった
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
12
“colopl_xcache” について
共有グラフ戦略はいけると確信、ただ障壁が見えてきた
もうこれは PHP 本体に入れてもらったほうがいいのでは... (既視感)
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
13
OPcache Static Cache について
PHP RFC として “OPcache Static Cache” を提案した
https://wiki.php.net/rfc/opcache_static_cache
https://externals.io/message/130912
中身は基本的に colopl_xcache をエンジンネイティブにし、かつ OPcache に統合することで JIT 利用時も Attribute を適切に扱えるようにしたもの
いつもの私の悪い癖: どうせ PHP 本体に入れてもらいたいのだから、と、 JIT での高速化まで取り入れ、変更規模を大きくしすぎた
結果:�レビューコストが大きすぎる。 OPcache に手を入れるのはかなり慎重にならざるを得ないし、 JIT はなおさら。また API 設計が適切でなく、かつ VolatileCache や StaticCache など新たな概念を導入したせいで feature creep となり厳しい状況に...
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
14
OPcache User Cache について
実はこれは表には出ていない
OPcache Static Cache から以下の点を改良した
が、そもそも継ぎ足し継ぎ足しで作っていたのでもはや自分でもわけがわからなくなってきたので、一旦そのものを破棄した
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
15
user_cache について
戦略だけを残し、フルスクラッチで作り直したもの。 OPcache の一部ではなく、 user_cache という名の全く新しい拡張機能
変更点
RFC: https://wiki.php.net/rfc/impl_user_cache
大問題: これが完全新規の RFC とみなされるのなら、 PHP 8.6 にはもう間に合わない！
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
16
“colopl_xcache” の詳細とこれから
ext-user_cache を PHP 8.1 ~ 8.6-dev まで用にバックポートし、改めて ext-colopl_xcache�として作成
現状ベンチマークハーネスにかけている限り速度もかなり良好
もしかしたらどこかの会社のオープンソースソフトとして公開されるかもしれない...�(本当に未定なのでわからない)
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
17
まとめ
できるからといって feature creep になるのヨクナイ
ちゃんとそれをレビューする側の気持ちになってみよう。�突然クソデカ PR 投げられたら相手がどう思うかちゃんと考えよう。
現実のワークロードをよく考えよう
Lazy hydrate など当初は画期的だと思ったが、そもそもアクセスしないものをキャッシュから引いてくるわけがなく、根本的に発想が悪かった。�ちゃんと PHP の実装をよく読み、共有グラフの道を最初から見つけるべきだった。
入ったとしてもPHP 8.7 になっちゃうかもです。すみません...
前述の通り RFC の扱われ方によっては 8.6 の Feature Freeze に間に合わない算段が高く�その場合は 8.7 、あるいは 9.0 になる可能性が高いです...�
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
18
ご清聴ありがとうございました
Questions to: @zeriyoshi (X/Twitter)
PHP Conference 2026 / opcache_static_cache, user_cache / Go Kudo (@zeriyoshi) Track #1
19