管理

PHP Realpath Cache：PHPのパフォーマンスを飛躍的に向上させる、見過ごされがちなツール

PHPのリクエストを高速化する、見過ごされがちな手法は PHPのRealpath キャッシュ：解決済みのパスをメモリに保存し、include/require 時の負荷の高いファイルシステムへのアクセス回数を削減します。Symfony、Laravel、または大規模な WordPress 環境を用いたプロジェクトでは、適切な Realpath の設定を行うことで、 パフォーマンス 測定可能であり、リクエストあたりのシステムコール数を大幅に抑えている。.

中心点

より簡単 Hebel：Realpathはパス解決結果を保存し、ファイルシステムへのアクセス回数を削減します。.
従業員1人あたり: 各PHP-FPMプロセスは、独自のRealpathキャッシュを管理します。.
サイズ 注意点：キャッシュが小さすぎるとスラッシングが発生し、リクエストの処理が遅くなります。.
TTL 最新性を制御：安定したデプロイには長いTTLを、シンボリックリンクやシークレットには短いTTLを設定します。.
モニタリング: realpath_cache_get()/size() は、利用状況と空き容量を表示します。.

Realpath Cacheが具体的にどのような役割を果たすのか

include、require、またはfile_get_contentsが実行されるたびに、PHPは相対パスを絶対パスに変換し、その結果を キャッシュ. 同じパスが再び入力された場合、メモリから結果を読み出し、コストのかかる ファイルシステム. この仕組みにより、特にComposerのオートローディングで多数のクラスや設定ファイルが読み込まれる場合、システムコールが著しく削減されます。重要：Realpathキャッシュはプロセスごとに存在するため、各PHP-FPMワーカーは、数回のリクエストを経て独自のキャッシュが構築されてから初めてその恩恵を受けられます。これにより、継続的な高速化効果が生まれ、高負荷時において特にその効果が発揮されます。.

大規模なフレームワークにおいてキャッシュが重要な理由

大規模なフレームワークや多数のプラグインは、リクエストごとに無数の ファイルへのアクセス, 、キャッシュがなければ毎回パスを再解決しなければならない。Realpathキャッシュの容量が小さすぎると、古いエントリが上書きされ、新しいエントリが追加されるが、そこで私は純粋な スラッシング. その結果、時間を要し、I/O負荷を高めるStatおよびLookup操作が繰り返し行われることになる。実運用では、これによりリクエストあたりのシステムコール数が約5～15 %削減され、リクエストレートが高い場合にはその効果が累積して大幅な削減につながる。アプリケーションのモジュール化が進めば進むほど、適切にサイズ設定されたRealpathキャッシュによる効果も大きくなります。.

適切なキャッシュサイズを算出する方法

まず、典型的なリクエストのユニークなパス数を数え、パスの平均長を推定し、エントリごとに約128バイトを加算します オーバーヘッド. 数、パス長、オーバーヘッドから、十分な バッファ を提供しています。多くの大規模なプロジェクトは4～16 MiBの範囲に収まりますが、非常に大規模なモノリポの場合はそれを超えることもあります。重要なのは、キャッシュが上限に張り付かないようにすることです。そうしないと、頻繁にキャッシュをクリアすることになり、その利点が失われてしまいます。私は段階的に容量を増やし、使用状況を観察しながら調整しています。.

推奨設定と例示値

デフォルト値は、コードベースが小さかった時代に由来するものであり、現在の状況にはもはや適合しないことがよくあります。 セットアップ. 多くの実用的なアプリケーションでは、realpath_cache_size を 4096K から 16384K に設定し、realpath_cache_ttl を 360～600 に延長しています秒あるいはそれ以上。重要なのは、プロジェクトの規模、デプロイ頻度、ファイルシステムの特性です。以下の表は、参考となる目安を示しており、チューニングを始める際の指針となります。その後、モニタリングや負荷テストを通じて数値を調整していきます。.

セッティング	頻繁な債務不履行	良好な初期値	期待される効果
リアルパス・キャッシュ・サイズ	4096K (4 MiB)	4096K–16384K	削減スラッシングファイルの数が多い場合
realpath_cache_ttl	120～600秒	360～900秒	より長いキャッシュホールド, 、再解散の減少

php.ini 内の例： realpath_cache_size = 4096K また、大規模なフレームワーク向けには realpath_cache_size = 16384K. 寿命に関しては、私はよく realpath_cache_ttl = 360 まれなリリースではそれ以上になることもあります。これにより、多数のリクエストにわたってパスがメモリ内に保持され、常に再検証される必要がなくなります。.

TTLを賢く選ぶ – 導入環境に応じて

適切なTTLは、デプロイプロセスや リンク 。シンボリックリンクのローテーションによってリリースを切り替える際、キャッシュが古いパスを返さないようにする必要があるため、TTLを短く設定するか、以下の処理後にFPMの再起動をトリガーするようにしています。 ロールアウト. Secrets や ConfigMaps をボリュームとして使用する Kubernetes 環境では、TTL を大幅に短縮するか、一時的に Realpath キャッシュを無効にします。一方、パスがめったに変更されない静的な Web ホスティング環境では、TTL を長く設定した方が効果的です。このようにして、環境に応じて最新性と速度のバランスを適切に調整しています。.

監視および検証

私は定期的に以下を使って確認しています realpath_cache_get(), どのパスが キャッシュ …にあり、そして…とともに realpath_cache_size(), 、そのうちどれくらいの容量が使用されているか。使用量が設定されたサイズに近づいている場合は、定員段階的に。キャッシュが極端に早くいっぱいになってしまう場合は、メモリの増設が必要か、あるいはTTLが短すぎるというサインだと解釈しています。大規模なプラグインのインストールやフレームワークのアップデートを行った後は、改めて確認します。数値を把握してこそ、適切なチューニングの判断ができるのです。.

測定可能な効果：システムコールとレイテンシの測定方法

チューニングの信頼性を確保するため、変更の前後に測定を行います。Linuxでは、リクエストごとのファイルシステム呼び出し数を次のように計測します。 ストレース 或いは パーフェクト, 、FPMワーカー1台またはCLIのいずれかで実行できます。.

単一のリクエスト（CLI）: strace -c -o /tmp/strace.txt php public/index.php 以下に、その数がいくつあるかについての概要を示します。 stat(), openat() そして lstat() 発生する。.
FPMワーカーを追加する: strace -fp -e trace=file -o /tmp/strace-fpm.log ファイルに関連する呼び出しのみを表示します。それ以前は、 ps ワーカーのPIDを特定する。.
負荷テスト: 以下のようなツールを使って より 或いは やあ 負荷をシミュレートし、キャッシュサイズが異なる場合のP95/P99レイテンシを比較します。.

それと同時に、PHPからキャッシュの割り当て状況を表示させます。例えば、デバッグ用エンドポイントやCLIなどを通じてです：

<?php
$entries = realpath_cache_get();
$size    = realpath_cache_size();
printf("エントリ数: %d, 使用量: %d バイト (%.2f MiB)\n", count($entries), $size, $size/1048576);

こうして、増額が リアルパス・キャッシュ・サイズ 単にRAMを消費するだけでなく、実際にミスやファイルシステム呼び出しの回数を減らします。理想的には、ヒット率が向上する一方で、P95レイテンシは顕著に低下します。.

Realpathキャッシュを的を絞って温める方法

キャッシュはワーカーごとに生成されるため、 ウォームアップ デプロイまたは再起動の後。目的は、実際のユーザートラフィックが流入する前に、最も頻繁に呼び出されるインクルードを早期にキャッシュに格納することです。.

リクエストのリプレイ: ロールアウト後に、典型的なURL（フロントエンド、管理画面、API）をいくつか自動的にテスト実行します。.
CLIのプライミング: 短いブートストラップスクリプトが、主要なパス（オートローダー、カーネル、設定、ルート）を読み込みます。.

<?php
// warmup.php
require __DIR__.'/vendor/autoload.php';  // Composer
require __DIR__.'/config/bootstrap.php'; // プロジェクトによる
require __DIR__.'/public/index.php';     // フロントコントローラー（短い実行をトリガーする場合がある）
echo sprintf("%dエントリをプリロード、%dバイトを使用\n",
    count(realpath_cache_get()), realpath_cache_size());

このウォームアップは、すべての実リクエストに対応するわけではありませんが、最も頻繁に使用される処理パスを事前に読み込んでおくことで、ワーカーごとの初期のコールドスタートフェーズを顕著に短縮します。.

OPcacheおよびファイルシステムキャッシュとの連携

OPcacheはPHPファイルの実行を高速化し、Realpathはファイルへのパスを短縮するため、私はこの2つを組み合わせています テクニック. OPcacheの設定については、実績のある値を使用しており、信頼できる情報源を参照しています。 OPcacheの最適化, 、バイトコードとパスが理想的に連携するようにするためです。さらに、Realpathは、ディレクトリ検索やメタデータを高速に提供する「ウォーム」なOSキャッシュの恩恵を受けています。これにより、読み込み時と解析時の二重の待ち時間を回避できます。この2つのレベルを連携させることで、応答時間の顕著な短縮を実現できます。.

Composerの自動読み込み機能を最大限に活用する

Composer-Autoloaderは、パス解決の主要な原動力です。その動作が確定的であればあるほど、Realpathキャッシュの負荷は軽減されます。.

クラスマップの最適化: composer dump-autoload -o ディレクトリのスキャンや繰り返し行われる検索を削減します。.
オートロードを厳守すると classmap-authoritative （プロジェクトの設定）では、余計なパス解決を引き起こしてしまうような不必要なフォールバックは避けています。.
構造を整理する: フラットで一貫性のあるフォルダ階層と、例外的なケース（例えば、モジュールやクライアントをまたぐインクルードなど）が少ないことが、キャッシュへの負荷を安定させます。.

その結果、リクエストあたりのパスバリエーションが減り、Realpathキャッシュでの再利用が増え、その結果、I/Oコストが削減されます。.

FPMとメモリ予算：ワーカー1人あたりで現実的な数値とは

Realpathキャッシュはプロセスごとに存在するため、設定されたサイズはFPMワーカーの数だけ倍増します。そのため、次のような予算を計画しています：

例: 12 ワーカー × 8 MiB = 96 MiB のリアルパス・ヘッド。これに加え、OPcache、PHP ヒープ、および拡張機能のオーバーヘッドが発生する。.
バランスをとる: OPcacheに十分な余裕があれば、Realpathにはさらに数MiBの容量が割り当てられる――あるいはその逆の場合もある。.
プール固有の: 異なるFPMプール（Front、Admin、API）は、それぞれのコードフットプリントに応じて、異なるRealpathサイズを設定しても構いません。.

リリースごとにコード量が増えれば、 リアルパス・キャッシュ・サイズ-通常、需要も伴います。そのため、アイドル状態だけでなく、負荷がかかった状態でのピーク稼働率も定期的に確認しています。.

特殊なケース：シンボリックリンク、コンテナ、NFS

シンボリックリンクの展開については、簡単に TTL または、デプロイ後にFPMを再起動して、すべてのワーカーが最新のパスを読み込むようにします。ボリュームが変更されるコンテナでは、キャッシュに古いデータが残らないよう注意しています。目標 TTLを調整することでこれに対処します。NFSでは、さらに適切なOPcache戦略を採用し、ディレクトリの切り替えを極力減らすことが推奨されます。実行時にパスが変更される場合、念のため、 clearstatcache(true) Realpathの部分も同様です。明確なデプロイルールにより、ワーカー間で一貫性を欠いた状態が生じるのを防ぎます。.

よくある障害や限界

キャッシュはプロセスごとに存在するため、各 労働者 まず、エフェクトが有効になる前にパスを収集しておく。open_basedir の制限が厳しい環境では、Realpath キャッシュの動作が制限されるため、この点を考慮に入れている バウンダリー 設計の段階において。キャッシュが小さすぎるとスラッシングが発生し、大きすぎるとRAMを無駄にする――私は測定を通じて最適なバランスを探っている。また、Realpathはメタデータやコンテンツのキャッシュではなく、あくまでパス解決の結果のみを保存するものである点にも留意しています。この点を誤解していると、他の箇所にある原因を見落としてしまうことになります。.

稼働の安全性：代表的な不具合の兆候と迅速な点検

いくつかの症状は、Realpathの問題を明確に示しており、すぐに確認することができます：

デプロイ後のレイテンシの急激な変動: シンボリックリンクのローテーション時のTTLが長すぎるか、ウォームアップが行われていないかのいずれかです。対処法：TTLを短く設定し、FPMを再起動した後、プライミングを実行してください。.
何度も繰り返された stat()-閲覧数と ストレース 目に見える形で現れる。多くの場合、キャッシュサイズが小さすぎるか、特定の動的パスがホットエントリを押し出している。.
ワーカー間のばらつきが大きい: プロセスごとにキャッシュが異なる。対策：一貫性のあるウォームアップと、リクエストの均等な分散。.

多くの場合、PHP を使った簡単なヘルスチェックで十分です：

<?php
$entries = realpath_cache_get();
$byDir = 0; $byFile = 0;
foreach ($entries as $e) { $e['is_dir'] ? $byDir++ : $byFile++; }
printf("ディレクトリ: %d, ファイル: %d, 使用量: %.2f MiB\n", $byDir, $byFile, realpath_cache_size()/1048576);

そうすることで、キャッシュの大部分を占めているのが主にディレクトリ（多数のモジュールやベンダー構造）なのか、それともファイル（多数の設定ファイルやクラス）なのかを確認し、構造やサイズを調整しています。.

Stat-Cache 対 Realpath-Cache：意図的に区別する

PHPは、Realpathキャッシュに加えて、 Stat-Cache ～の結果については stat() および関連する呼び出し。両方のキャッシュは、 clearstatcache() 影響を与える：

clearstatcache() Statキャッシュをクリアします（特定のファイルに対してはオプションです）。.
clearstatcache(true) さらに、Realpathキャッシュをクリアします。.

ごくまれなケース――たとえば、動的マウントを使用する長時間実行型のCLIワーカーやホットスワップの場合など――では、意図的に clearstatcache(true)-既知の変更があった場合にのみフックを実行します。それ以外の場合は、TTLを機能させたままにし、不必要な無効化を避けます。.

ホスティング環境の実践チェック

まず、プロジェクトの規模、つまり一般的なリクエストで読み込まれるファイル数を把握し、その後、 キャッシュ. 。その後、頻繁に使用されるすべてのパスに加え、予備分も収まるような realpath_cache_size を選択し、デプロイの頻度に合わせた TTL を設定します。その後、モニタリングやログでその効果を確認し、値を無闇に大きくするのではなく、慎重に調整していきます。さらに、OSのキャッシュ、例えばLinuxの設定についても確認しておく価値があります。 VFSキャッシュ圧力, 、というのも、Realpathはディレクトリの高速検索の恩恵を受けるからです。このようにして、副作用を見逃すことなく、改善を重ねていくのです。.

適用範囲と設定方法：どこでどの値を設定するか

環境に応じて、パラメータを異なる場所で設定しています：

グローバル: php.ini システム全体のデフォルト設定について。.
プロ・プール: FPMプール内では、 php_admin_value[realpath_cache_size] そして php_admin_value[realpath_cache_ttl] フロントエンドとAPIに合わせて、それぞれ異なるサイズ設定を行う。.
Proディレクトリ: 『In』 .user.ini （許可されている場合）、共有ホスティング環境では有用です。.

重要： php.ini また、FPMプール設定については、ワーカーが新しい設定値で起動するように、再起動またはリロードが必要です。.

CLI、キューワーカー、およびCronジョブ：ルールは同じだが、実行時間は異なる

CLIスクリプトやキューワーカーもRealpathキャッシュの恩恵を受けますが、ただし 耐用年数 多くの場合、異なる：

短時間のCLIジョブ: 呼び出しごとにキャッシュが新たに生成されます。この場合、ウォームアップや長いTTLはあまり効果がありません。むしろ、ジョブ内での繰り返しインクルードがキャッシュされるように、十分なサイズを確保することが重要です。.
デーモン／ワーカー: 長時間実行されるプロセス（Supervisor、Systemd）は、安定したキャッシュを構築します。その後、 コードのリロード （デプロイ）の後、プロセスを再起動する必要があります。そうしないと、キャッシュに古いパスが残ってしまう可能性があります。.

プロジェクト規模の推定と貯留効果

4000個の固有のパスと、各エントリにつきパス長80バイト＋オーバーヘッド128バイトを持つアプリケーションの場合、おおよそ832 KBが必要となる メモリ Realpathキャッシュ内。余裕を見て4 MiB以上を想定している。プラグインやモジュールによってコードベースが大幅に拡大した場合は、それに比例してスケールアップし、再度 ヒット数 versus ミス。共有ホスティング環境では、小さなファイルが多すぎるとシステム全体に負荷がかかるため、iノードの制限にも注意を払っています。その点、この概要が参考になります。 iノードの制限. 常に限界まで使い切るよりは、余裕を持たせておくほうが賢明だ。そうすれば、不要なRAM消費を抑えつつ、システムコールの回数を減らすことができる。.

手短に言うと：私のチューニング計画

まずリクエストごとのファイル数を計測し、その後、適切な キャッシュサイズ そして、デプロイの実務に適した TTL. 。その後、realpath_cache_get()/size() を使って負荷状況を確認し、段階的に調整を行い、OPcache や OS キャッシュの微調整と組み合わせます。シンボリックリンクを展開する際はTTLを短く設定するか、FPMを再起動します。静的な環境では、長いTTLを使用します。目標は、RAMを無駄にすることなく高いキャッシュヒット率を維持することです。このようにして、Realpath Cacheという過小評価されがちなツールを活用し、一貫したPHPパフォーマンスを実現しています。.