...
ウェブホスティングのロゴ

なぜWordPressはオペコードキャッシュなしで高いパフォーマンスを発揮できないのか？

Opcode Cache WordPressは、サイトがPHPを呼び出すたびにリコンパイルするか、RAMから直接起動するかを決定します。OPcacheの欠落がPHPのコンパイルに影響を与える理由を説明します。 CPU 荷が重い。 TTFB スケーリングは著しく制限される。.

中心点

詳しく説明する前に、最も重要な発見を簡潔かつ明瞭に要約する。OPcacheがないと、PHPはリクエストごとにリコンパイルし、待ち時間とリソースを浪費し、ページが応答しなくなる。OPcacheを有効にすると、バイトコードとコードパスはメモリ不足になり、リクエストはより速く戻り、ロードスパイクはそれほど頻繁にエスカレートしなくなります。ページ・キャッシングやオブジェクト・キャッシングと組み合わせることで、OPcacheは効率を高め、サブ構造に必要な落ち着きをもたらします。OPcacheを正しく設定すると、サーバーコアあたりのポータブルユーザー数が顕著に増加し、ピーク時のエラー率が減少します。これらの点は、低速なシステムと、高速なシステムの違いをコントロールする。 速い 信頼性の高いインストール パフォーマンス.

  • オペキャッシュ コンパイル時間を節約し、安定させる TTFB.
  • CPU負荷 が減少すると、1人当たりの生産能力が低下する。 コア が増える。
  • スケーリング 成功してもピークは残る 可変.
  • PHP 8以上 さらに パフォーマンス.
  • モニタリング 命中率を維持し メモリ 一目瞭然。

WordPressがオペコードキャッシュなしで遅くなる理由

WordPressはページリクエストごとに多くのPHPファイルを読み込みますが、OPcacheを使わずにその都度解析し、シンタックスツリーに変換してバイトコードに再コンパイルします。 計算時間 不必要に長くなる。なぜなら、同じルーチンがリクエストのたびに最初から完全に開始されるため、実行時間が2倍から3倍になる。 CPU を発生させる。この繰り返しはFPMワーカーをブロックし、応答を遅らせ、TTFBを急上昇させる。同時アクセス時のスループット率は低下し、エラー率（502/504）はピーク時に上昇する。プラグインや重いテーマが多ければ多いほど、個々のアンキャッシュのコストは大きくなります。.

OPcacheの詳しい仕組み

OPcacheはコンパイルされたPHPバイトコードを共有メモリに保存し、タイムスタンプが変更されていない場合は同じコードをRAMから直接配信します。 ディスク-アクセスや再コンパイルはもはや必要ない。パーサーとコンパイラーのステップがなくなり、エンジンはすでにバイトコードとして利用可能なものだけを実行すればよいのです。この動作により、リクエストごとのシステム・オーバーヘッドが大幅に削減され、負荷がかかっても応答時間が安定する。そのため、WordPressでは、オブジェクトやページのキャッシュを開始する前に、最初の対策としてOPcacheをインストールしています。この節約は、多くの小さなファイルに分散され、乏しいファイルとの違いを生み出します。 リラックス サーバーの負荷。.

測定可能な効果TTFB、CPU、容量

OPcacheを有効にすると、繰り返されるリクエストの実行時間が最大3倍短くなることがよくある。 TTFB と、レンダリングのための時間予算が増加します。同時に、コンパイル作業がなくなり、ワーカーがより迅速に解放されるため、典型的なWordPressワークロードのCPU使用率が50～80 %減少します。その結果、同一のハードウェアで動作可能な並列ユーザーの数が増え、P95/P99の範囲内の異常値が少なくなります。マーケティング・キャンペーンや季節的なピーク時には、キャンセルが減り、買い物カゴの数が増え、ランキングが安定します。ページキャッシュとオブジェクトキャッシュが統合されれば、これらの効果はさらに高まりますが、OPcacheなしでも基本は変わりません。 非効率的 そして、その上の層がより早く接触する。 驚異的.

OPcacheとその他のキャッシュの相互作用

それぞれの役割を明確に分けることができるように、それぞれのレベルを対比させ、どのように補完しあっているのか、しかし代替しているわけではないことを説明しよう：OPcacheはコード実行を高速化し、ページ/オブジェクトキャッシュはコンテンツとデータアクセスを緩和します。OPcacheは、PHPのすべてのパスを高速化し、PHPのすべてのパスを高速化し、PHPのすべてのパスを高速化し、PHPのすべてのパスを高速化し、PHPのすべてのパスを高速化するからです。 CPU を取ります。そして、ページ・キャッシングを使って繰り返しページを直接配信し、オブジェクト・キャッシングを使ってデータベースに対するクエリを減らす。下位レイヤーが欠けていると、上位レイヤーはロードジャンプを十分に補うことができない。次の表は、レイヤーを選択するための簡単なオリエンテーションです。 期待.

キャッシング・タイプ 保存場所 ワードプレスのメリット 典型的な利益
オペキャッシュ サーバーRAM PHPバイトコードを保存し、パース/コンパイルを保存する 最大3倍の実行時間短縮
オブジェクト・キャッシュ Redis/Memcached DB クエリの結果セットを保持 DBの負荷が大幅に軽減
ページキャッシュ ディスク/プロキシ/CDN ゲスト用のHTMLを用意 ほぼ即答

WordPressのOPcache設定の最適化

私は常にOPcacheをenable=1に設定し、メモリに余裕を持たせ（プラグインのランドスケープによって128～512MB）、max_accelerated_filesを増やして、インデックスが完全なままで ヒット率 は劣化しない。本番では、キャッシュが不必要に無効にならないように、タイムスタンプの自動チェックを停止するか、頻度を減らし、制御されたクリアをスケジュールする。大規模なサイトでは、メモリ不足のイベントを発生させず、JITパフォーマンスを損なわない専用のメモリプールを用意するのが得策だ。私は、キャッシュを健全に保つために、ヒット率（%で95以上）、空き共有メモリ、孤児エントリを定期的にチェックしている。システマティックなセットアップの詳細については、私の OPcacheの設定, これは、わずか数ステップで安定したタイムにつながり、次のようなものだ。 コンスタンス レスポンスが強化される。.

プリロードとJIT：利点と限界

PHPは7.4からプリロードをサポートしており、選択されたファイルはマスタープロセスですでにロードされ、メモリに配置されます。しかし、古典的なWordPressのセットアップでは、コアと多くのプラグインが非常に動的にロードされ、コードパスがルートによって異なるため、これは管理可能な付加価値しかもたらしません。プリロードは特に、ホットパスが明確で、フレームワークを多用する同種のプロジェクトで有用です。プリロードを試したい場合は、プリロードリストを小さく、安定させ、バージョンに依存しないようにしてください。また、FPM のリロードによってプリロードセットが再構築されることに注意してください。.

コンテンツのワークロードでは、JITに目立った利点はないと思う。WordPressのリクエストの多くはI/Oとテンプレート駆動型であり、数値的な負荷は高くない。アグレッシブなJITモードは共有メモリを消費するが、OPcacheにはそれがない。私は実運用では保守的なアプローチをとっている。JITをオフにするか、バイトコード・キャッシュが最大スペースを確保できるように適度なレベルにしている。.

; php.iniの抽出 - WP互換の保守的な設定
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=100000
opcache.validate_timestamps=0
opcache.revalidate_freq=60
opcache.save_comments=1

JITを減らすか無効にする
opcache.jit=0
JITを減らすか無効にする：
opcache.jit=1205

オプションでプリロードを行う。
; opcache.preload=/var/www/preload.php
; opcache.preload_user=www-data

設定ミスの認識と修正

多くのインストレーションでは、メモリプールが小さすぎたり、accelerated_filesが少なすぎたり、積極的なタイムスタンプ検証が行われなかったりしている。 効果 の OPcache を大幅に改善しました。私はphpinfo()を分析し、キャッシュエンジンの統計情報を監視し、実際のデプロイメントと比較して、リークやスラッシュの挙動を見つけます。プラグインのセットやテーマが大きくなれば、キャッシュもそれに追いつかなければなりません。そうでなければ、ヒット率が低下し、実行時間が長くなってしまいます。私は明確な制限を使っている：一日の間にOOMがないこと、ヒットレートを100 %に近づけること、revalidate_freqをミリ秒ではなく秒単位で行うこと。私のガイドに構造化されたチェックリストがある。 ミスコンフィギュレーションの最適化, 典型的なつまずきの原因を取り除き 安定性 を確保する。.

パフォーマンスを低下させることなく、無効化とデプロイメントを実行

よくあるエラーは、小さなアップデートのたびにキャッシュを完全に空にしてしまうことだ。 ユーザー 遅れを感じる。そのため、私はファイルレベルで制御された無効化を計画し、オフピーク時にリリースを展開し、ウォームアップ処理を実行している。CI/CDでは、事前に重要なルートを実行し、トラフィックが到着する前にバイトコードをメモリにロードするプリロード・スクリプトを使用している。こうすることで、パフォーマンスのピークを避け、デプロイメントを通じてページスピードのメトリクスを安定させることができる。の記事に最も重要な戦術をまとめた。 OPcacheの検証 をリリースする。 ソフト しかも、巻き添えを食うことなく。.

ファイルシステム、パス、リアルパスキャッシュ

多くの問題は、OPcache自体で発生するのではなく、ファイルシステムとの相互作用で発生する。同じファイルへの異なるパス（シンボリックリンク、chroot、複数のマウントポイント経由など）は、重複を生み出し、インデックスを肥大化させる可能性がある。そのため、私は一貫したインクルード・パスに注意を払い、デフォルトのopcache.use_cwd=1とrevalidate_path=0を使用して、ファイルが一意性を保つようにしています。マルチテナント環境では、さらにvalidate_permission=1とvalidate_root=1で隔離を確保し、外部パスのクロスビューがないようにしています。NFS共有では、チェックの頻度を減らし、タイムスタンプのドリフトがスラッシュの無効化を引き起こさないようにアトミックにデプロイします（シンボリックリンクを解放します）。.

忘れられがちな調整ネジは、PHPのリアルパスキャッシュです。これはパスの解像度を節約し、リクエストごとの高価なstatコールを減らします。大規模なWPのインストールでは、頻繁に使用するパスが常に再計算されないように、高めに設定します。.

; パス解像度の高速化
realpath_cache_size=1M
realpath_cache_ttl=600

マルチサイト、MUプラグイン、Composerの構造

WordPressのマルチサイト、広範なMUプラグイン、Composerベースのセットアップでは、多くの小さなファイルが使用されます。インデックスを完全な状態に保つために、私は早い段階でmax_accelerated_filesを増やし（サイズに応じて80-200k）、共有メモリを確保する。そうしないと、同じバイトコードが何度もキャッシュに入ってしまいます。やむを得ない場合は、安定したタイムスタンプやブラックリストで保護し、恒久的な再コンパイルが発生しないようにします。Composerのオートロードはクリティカルではないが、数が多い - 余裕のあるインデックスがヒット率に直接影響する。.

ホスティングの影響：PHPバージョン、FPMワーカー、RAM

PHP 8.0+では、7.4と比較して顕著な向上がすでに得られており、8.5のような新しいバージョンではさらに大きな向上が得られています。 ベースライン OPcacheの利益が増える。私は十分な数のFPMワーカーを起動するが、サーバーが実際に処理できる数より多くは起動しない。OPcache用の共有メモリには、成長を緩和し、常時退避圧力を発生させないリザーブが必要です。WordPressは多くの場合、チューニングされていないVPSインスタンスよりも、優れた基本設定の共有プランの方がスムーズに動作する。決定的な要因は、バージョン、プロセス数、RAMの調和のとれたセットアップが実際の 負荷 フィットする。

CLI、WP-Cron、バックグラウンドジョブ

FPMに加えて、多くのWordPressタスクがCLI経由で実行されます：WP-Cron、Indexer、画像処理、インポート、WP-CLIコマンドなどです。デフォルトでは、OPcacheはCLIのために非アクティブになっており、これは再起動のジョブが毎回再コンパイルされることを意味します。CLIを頻繁に実行するサーバーでは、CLI用のOPcacheを有効にして、ファイルキャッシュを追加しています。これにより、バイトコード・アーテファクトをCLI呼び出し間で再利用できるようになり、繰り返し実行されるタスクが明らかに高速化される。.

; CLIジョブにもOPcacheを使う
opcache.enable_cli=1
opcache.file_cache=/var/cache/php/opcache
opcache.file_cache_only=0
opcache.file_cache_consistency_checks=1

重要: CLIキャッシュはFPMキャッシュとは別のもので、バックグラウンドジョブを緩和しますが、FPMプールのウォームアップを置き換えるものではありません。多忙なcronウィンドウの場合は、短いウォームアップスクリプトを計画することで、FPMワーカーがホットなバイトコードでシフトを開始し、ピーク・トゥ・ピークの影響がないようにする。.

コンテナ、オーケストレーション、ローリングデプロイ

DockerやKubernetes環境では、ポッドはしばしば再起動されたり、水平方向にスケールされたりします。すべての新しいFPMマスターは、空のSHMセグメントから始まります。ウォームアップなしで、最初のライブリクエストはコールドスタートを実行します。そのため、重要なルートや管理フローを一度「プリクリック」するinitコンテナやプリスタートフックを使用している。ホットパスがOPcacheにあるときだけ、レディネス・プローブを起動するようにしている。シンボリックリンク・リリースを使用したローリング・デプロイでは、選択的に起動し、古いプールを制御された方法で期限切れにし、ウォームアップと健全性チェックがグリーンになったときにのみ、新しいリビジョンにトラフィックを誘導する。短命なコンテナでは、opcache.file_cacheを使用することで、コールドスタート時間をさらに短縮することもできる。.

実践例と健康的なガイドライン

多くのショートコードを含む中規模のWooCommerceサイトで、OPcacheはCPUスパイクを半減させ、同時セッションのポータブル数を倍増させました。 ターンオーバー がピークに達した。ページキャッシュはあるがOPcacheはないコンテンツポータルは、バイトコードキャッシュによって解析負荷がなくなるまで、高いTTFBを示し続けた。ブロック・エディターがあるブログも、多くの小さなPHPファイルが関係し、メモリ・インデックスが繰り返し作業をなくすので、同様に恩恵を受ける。現実的には、小規模なサイトでは128-192MB、大規模なセットアップではファイル数にもよりますが256-512MBの共有メモリを計画しています。これらのガイドラインに従い、統計をチェックすれば、レスポンスタイムは信頼できるものになるでしょう。 ロー そして、リスクと コスト.

日常生活における監視と検証

私は直感に頼らず、OPcacheのメトリクスを定期的にチェックし、実際のレイテンシーと関連付けている。ヒット率に加えて、used_memory、free_memory、wasted_memory、interned_stringsの利用率に興味がある。free_memoryと空きハッシュスロット数が常に高いままであれば、セットアップは健全である。wasted_memoryが恒常的に増加するようなら、整頓（計画的リセット）するか、プールを増やす。.

<?php
$status = opcache_get_status(false);
$mem = $status['memory_usage'];
$stats = $status['opcache_statistics'];
printf(
  "Hit-Rate: %.2f%%\nUsed: %.1f MB, Free: %.1f MB, Wasted: %.1f MB\nCached Scripts: %d\n",
  $stats['opcache_hit_rate'],
  $mem['used_memory']/1048576,
  $mem['free_memory']/1048576,
  $mem['wasted_memory']/1048576,
  $stats['num_cached_scripts']
);
?>

同時に、TTFB、P95/P99、Apdexをゲストとログインユーザーで別々に測定した。OPcacheが正常に動作している場合、ウォームアップ後にカーブは安定し、ピークはかなり平坦になります。メトリクスとOPcacheのステータスが乖離している場合（ヒット率は高いがTTFBが低いなど）、次にDBクエリ、ネットワーク、ストレージ、または外部サービスのブロックを調べます。.

高速WPインスタンスへのステップバイステップ

まずPHP 8.xにアップグレードし、OPcacheを有効にして、memory_consumptionとmax_accelerated_filesがプロジェクトにマッチし、OOMエントリが表示されないことを確認します。それから、validate_timestampsとrevalidate_freqをデプロイ時の慣行に合わせて調整し、不要な無効化を回避して スループット を確保する。その後、ログイン時とゲスト時のTTFB、Apdex、P95のレイテンシを測定し、実際の進捗を記録します。それから初めて、オブジェクトキャッシュ（Redisなど）とページキャッシュを追加して、データベースとHTML配信の負荷を軽減します。このロードマップによって、私は確かなベースラインを設定し、残りのロードマップの基礎とする。 パフォーマンス で。

簡単にまとめると

OPcacheがないと、WordPressはすべてのリクエストにコードの再パースと再コンパイルを強いることになり、TTFBが上昇し、ワーカーがブロックし、そして 定員 が縮小する。アクティブ・バイトコード・キャッシュを使えば、まさにこの作業を節約し、CPU負荷を大幅に軽減し、ピーク時の予備を得ることができる。テストでは、OPcacheは繰り返しの呼び出しを最大3倍高速化し、PHP 8.xはさらなる高速化と基本負荷の軽減を実現した。クリーンな設定、慎重な無効化、監視により、ヒット率は高く維持され、共有メモリはボトルネックから解放されます。これらのステップに一貫して従えば、WordPressの動作が明らかに速くなり、安定し より経済的.

現在の記事