問題
開発中の Drupal Web サイトのパフォーマンスの問題を診断しようとしています。午前中、サイトに 8 時間以上トラフィック (cron の実行さえも) がない場合、ホームページの読み込みに約 3.5 秒かかります。ページの再読み込みには、予想どおり 250 ミリ秒かかります。
これは開発用 Web サーバーで、かなり古いバージョンの PHP (5.3.3) がインストールされています。すべてのファイルはNFS経由で静的にマウントされています(これが根本的な原因であると私は考えています。詳細は後述します)。
診断を助けるために、私はインストールしましたXHプロフこの開発サーバーで、ページの読み込みをプロファイルし、プロファイル データを整理しやすい表に表示する Drupal モジュールを有効にしました。XHProf に馴染みのない方のために説明すると、XHProf は呼び出されたすべての関数に関するデータと、その関数の合計所要時間、メモリ使用量、呼び出し回数などの情報を提供します。
私の発見
最初の「遅い」ヒットでは、PHP関数file_existsは1400ミリ秒82回の呼び出しから、全体の実行時間の約43%を占めています。その後のページ読み込みでは、同じ関数file_existsが再び82回呼び出されましたが、今回は大幅に短縮されました。3ミリ秒全体の実行時間のわずか 1% を占めます。
さらに、PHPがメモリにロードするのに最も時間がかかったファイル（load::関数名のプレフィックスはこれを意味すると思います）を調べました。このPHPテンプレートファイルは、42ミリ秒最初に読み込むだけで、3ミリ秒その後のリロードで！
私が疑っているのは
どこかで何らかのキャッシュが行われているのは明らかですが、まだどこなのかはわかりません。PHPドキュメントにはファイルが存在していますこの関数の出力はキャッシュされるということが書かれています。このキャッシュのサイズを制御するまた、デフォルトの 16k から、大量の相対ファイルを読み込む Drupal に適した値に増やす必要があるでしょう。
しかし、そうすることで に費やす時間が短縮されると思う一方でfile_exists、実際に PHP にかかる時間に影響するかどうかはわかりません。読み込み中ファイル (load::前述した) とこの値を増やすと、ファイル システムの根本的なパフォーマンスの問題が隠れてしまうだけのようです。
質問
- XHProf または PHP のベテランで、PHP の増加がXHProf から
realpath_cache報告される時間に影響を与えたかどうかを確認できる方はいらっしゃいますか?load:: - Linux では、影響を与える可能性があるどのような基礎的なキャッシュ メカニズムに注意する必要がありますか?
- 上記と同じですが、NFS 用ですか?