ワードプレス

WordPressのクエリー・キャッシュ：なぜキャッシュは通常、益よりも害をもたらすのか？

仝 WordPressクエリキャッシュ はロード時間の短縮を約束するが、実際にはしばしば無効化を引き起こす、, レイテンシー そして一貫性のないコンテンツ。このキャッシュがWordPressのセットアップでしばしばパフォーマンスを低下させる理由と、その代わりに安定したスピードを実現する方法を紹介しよう。.

中心点

無効化頻繁な書き込み操作はキャッシュを空にし、オーバーヘッドを発生させる。.
レイテンシー外部キャッシュは接続時間を増加させるので、節約分を食いつぶしてしまうことが多い。.
矛盾古い入力は、古い価格、不正確なリスト、空の買い物かごにつながる。.
RAMキャッシュはPHP、MySQL、Nginx/Apacheとメモリを奪い合う。.
代替案ページキャッシュ、OPcache、クリーンなクエリは、確実な利益をもたらします。.

WordPressのクエリキャッシュの仕組み

MySQL は SELECT クエリの結果を正確な SQL テキストを使用して キャッシュ そして、同一のクエリで再度配信することで、実行を保存します。しかし、WordPressでは、INSERT、UPDATE、DELETEが連続的に受信され、影響を受けるテーブルのクエリキャッシュが即座にロードされます。 使用不能. .私は定期的にログで無限ループを見ます：充填、空、再び充填 - サーバーは顕著な利点なしにCPU時間を消費します。さらに、MySQLのクエリキャッシュは、トランジェントやオブジェクトキャッシュといったWordPress独自のメカニズムと衝突し、待ち時間を短縮する代わりに増加させる。そのため、WordPressのクエリキャッシュを利用する人は、二重のキャッシュレイヤーを構築してしまい、キャッシュレイヤーがサポートできる速度よりも早く壊れてしまうことになる。.

定義：ここで実際にキャッシュされているもの

私は、しばしば混同される3つのレベルを区別している：

MySQLクエリキャッシュ同一の SELECT ステートメントに対する結果キャッシュ。影響を受けるテーブルへの書き込み操作はすべてエントリを無効にする。これはWordPressのような最新のOLTPワークロードでは逆効果である。新しいMySQLのバージョンでは、このキャッシュも時代遅れである。MariaDBではまだ存在するが、私はそれもオフにする。.
InnoDB バッファプール結果キャッシュではなく、データとインデックスページのページキャッシュです。これは、繰り返し行われる読み取りアクセスのための堅牢で実績のあるパスである。しっかりとしたバッファプールサイズは、どの結果キャッシュよりも多くの結果をもたらすことが多い。.
WordPressのオブジェクトキャッシュ/トランシエントWP_Queryの結果、オプション、フラグメントHTMLなどの準備された構造が格納される。このレイヤーは、読み取りアクセスがルールであり、無効化が確実に機能する場合にのみ役立ちます。.

日常生活では、バッファプールとよく選択されたページキャッシュが最大のレバーであることを私は観察してきた。追加のクエリー・キャッシュが正味の利益をもたらすことはほとんどなく、複雑さ、待ち時間、不整合のリスクを増大させる。.

助ける代わりに減速させる理由

共有ホストやWooCommerceでは、キャッシュが顕著に生成されます。遅延, なぜなら、RedisやMemcachedにネットワーク接続するたびに時間がかかり、ほとんどヒットしないからだ。高速なマシンでも、リクエストごとにミリ秒単位でロスすることが多く、それがトラフィックに加算され、time-to-first bytesが膨れ上がる。さらに、無効化フックがなかったり、プラグインが正しく動作しなかったりすると、結果が古くなるリスクがある。価格または見逃した銘柄。もっと詳しくご覧になりたい方は、私の体験レポートをお勧めします。オブジェクト・キャッシュ・ブレーキなぜなら、同様のパターンがクエリー・キャッシング・レベルにも当てはまるからである。平均して、優れたスキーマとOPcacheを持つデータベースへのクリーンな直接アクセスは、より優れた安定した応答時間を達成する。.

キャッシュスタンピード、TTL、調整

WordPressのスタックで繰り返されるパターンは キャッシュスタンピード1つのエントリーの有効期限が切れると、多くのリクエストが同時に同じ高価なクエリーを行い、スパイクを発生させる。連携していないクエリーとオブジェクトのキャッシュは、これを悪化させる。私はこれを避けるために3つの戦略を使っている：

ロック/コアレスあるリクエストはエントリーを構築し、他のリクエストは少し待つか、古い値を返す (有効期限切れ)、バックグラウンドで更新される。.
便利なTTL任意の24時間基準はない。商品リストや価格の断片は短いTTL（秒/分）を受け取り、カタログのメタデータは長いTTLを受け取る。.
イベントベースの無効化露骨なタイムシーケンスの代わりに、私はフック（例えばポストアップデート）を使って、影響を受けるキーだけを削除している。.

重要：ワードプレスでは トランジェント アクティブな永続オブジェクトキャッシュで効果的 パーマネント を保存した。ここできれいな無効化を行わないと、再現が困難な矛盾やエラーパターンを生み出すことになる。.

生産現場における典型的な症状

WordPressのクエリキャッシュが破損した場合、私はまず、以下のように変動することでそれを認識する。 応答時間, これは、コードを変更することなく、突然上がったり下がったりする。夕方になると、さらに注文が入り、無効化が積み重なり、サイトはキャッシュミスと新規エントリーのスパイラルに陥る。モニタリングでは、PHP-FPMが新しい結果を待つ間、MySQLのCPUが不安定なピークを示す。同時に、重複したコメント、空のショッピング・バスケット、商品ウィジェットの更新遅延などのミスマッチが報告されます。また、競合するプロセスが常に同じテーブルに書き込んでいるため、キャッシュが無効になり、ロック警告がログに表示されることも増えている。.

キャッシング・レベル：スタッキングの代わりにシーケンス

私は影響連鎖に従ってキャッシュに優先順位をつけている：

ブラウザ/CDN/エッジキャッシュ クッキー/ヘッダーによって区別される、完全に公開されたページの場合。.
ページキャッシュ スタック(ウェブサーバー/プラグイン)内で、理想的にはプリロードとイベント時のターゲットパージを行う。.
オペキャッシュ 一貫してコンパイルされた PHP バイトコード用です。.
オブジェクトキャッシュ 高価で、めったに変更されないオブジェクトに対してのみ選択的に使用される。.
データベース 強力なスキーマ、インデックス、大きなバッファプールを持つ。.

この順番を守る者は、TTFBを減らすだけでなく、何よりも分散 - ユーザーが「ジャーク」と感じるもの。.

実速度に対するより良いオプション

私は、まず最初に、確実にパフォーマンスを上げる。 ページ・キャッシング ページキャッシュを有効にし、OPcacheを適切に設定し、データベースクエリを効率化します。ページキャッシュはHTMLを配信し、データベースの負荷をゼロにし、負荷のピークをスムーズにします。OPcacheはPHPを一度コンパイルするので、PHP-FPMの作業が減り、TTFBが減少する。Redisを使ったオブジェクト・ベースのキャッシュは、サーバー・リソースに余裕があり、アプリケーション・ロジックがページごとの書き込みアクセスをほとんど発生させない場合にのみ価値がある。このシーケンスでは、ボトルネックをソースから排除し、可動部分の数を管理しやすくします。 バッファメモリ を維持する。.

測定	主なメリット	リスク／専門性
ページキャッシュ（静的HTML）	非常に低い TTFB, DB負荷がほとんどない	内容が変更された場合は、特に更新されなければならない
OPcache（PHPバイトコード）	CPU時間リクエスト	一貫した展開とウォームアップ戦略が必要
Redisオブジェクトキャッシュ	頻繁なアクセスオブジェクト	RAMを消費し、クリーンなキーデザインが必要。
MySQLクエリキャッシュ	理論的にはクエリ実行回数が減る	高い無効化作業、不整合リスク、追加のオーバーヘッド

実践ガイド：代替案の無効化とテスト

まずMySQLを使い、システムレベルでクエリーキャッシュをオフにする。 クエリキャッシュタイプ に於いて 0 そして クエリキャッシュサイズ に於いて 0 セット。それからWordPressを整理する：ドロップインや定数がオブジェクトキャッシュを強制する場合は、テストとして define('WP_CACHE', false)；;. .その後、Query MonitorやBlackfireなどのツールやシンプルなメトリクス（TTFB、クエリー/リクエスト、CPU）を使って、ページごとの実際の影響を測定します。ページキャッシュが設定され、PHP/OPcacheが適切に動作している場合にのみ、小規模なRedisレイヤーが個々のホットスポットの負荷を軽減するかどうかを具体的に評価します。この順序により、再現性のある結果が得られ、以下のことが確実になります。 安定性, チャンスヒットを期待するのではなく.

その価値が証明された具体的な構成

私が定期的に安定した利益を達成しているいくつかのデフォルト（常に自分のシステムで検証してください）：

MySQL/MariaDB:

[mysqld］
query_cache_type=0
query_cache_size=0
innodb_buffer_pool_size=60-70%_vom_RAM
innodb_flush_log_at_trx_commit=1
slow_query_log=1
long_query_time=0.2
log_queries_not_using_indexes=1

バッファプールが主な負荷を負担している。私は開発者に遅いログを見せ、N+1とSELECT *パターンを計画的に削除している。.

オペキャッシュ:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=100000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
古典的なWordPressのスタックのためのJITはむしろオフ：
opcache.jit=0

一貫したデプロイ（アトミックなシンボリックリンクなど）と、リリース後のウォームアップは重要だ。.

ピーエッチピーエフピーエム:
```
pm=dynamic
pm.max_children=<CPU/RAMによる
pm.max_requests=500-1000
process_idle_timeout=10秒
    
```
これは、コールドスタートを誘発することなく、漏れや断片化を緩和する。.
レディス (使用する場合）：
```
maxmemory <RAMバジェット
最大メモリポリシー volatile-lru
tcp-backlog 511
遅延を最小にするため、UNIXソケット経由でローカルに優先する
    
```
私はRedisをローカルか同じAZ/ホストでしか使わない。遅いネットワークでは、すぐにレイテンシの増幅器になってしまう。.

データベースをクリーンに保つインデックス、クエリ、プラグイン

キャッシュをスタックする前に、クエリを最適化する。 インデックス, なぜなら、最大の時間短縮は優れたデータ作業から生まれるからだ。長すぎるJOIN、SELECT *、WHERE条件の欠落、インデックスなしのソートなどは、どんなキャッシュが節約できるよりも多くの時間を浪費する。私は、オートロード戦略なしでwp_optionsに多くのオプションを保存しているプラグインを定期的にチェックし、余計な拡張機能を削除している。対象となるヘルパーは、独自のSQLパターンを表示して効率化することです。データベースクエリの最適化. .クリーンなクエリ規律があれば、サーバーへの負担は目に見えて減少し、WordPressのクエリキャッシュの利点とされるものは、隠すものが何もなくなるので、それ自体で解決する。.

キャッシングに勝るホスティング要因

宜しい CPU-パフォーマンス、高速なNVMe SSD、十分なRAM、最新のMySQLのバージョンは、壊れやすいクエリー・キャッシュよりも大きな違いをもたらします。キープアライブ、HTTP/2またはHTTP/3、適切なタイムアウト、無駄のないPHPプロセスプール。OPcacheは、頻繁に使用するスクリプトのバイトコードが完全に収まるように、余裕を持ったサイズにしています。同時に、ピーク時にクエリの嵐を引き起こすcronジョブやバックグラウンドタスクを制限している。これによって、ページ・キャッシングとターゲット・オブジェクト・キャッシングをピンポイントで使用できる、強固なベース・パフォーマンスが生まれる。 回避策 を失う。.

測定方法：効果の評価方法

私はまず、次のように測定する。 ベースライン クエリーキャッシュなしで、コールドスタート、ウォームスタート、そしてJMeterかk6で50から200リクエスト。その後、1つのセットスクリューだけをアクティブにし、決して複数のセットスクリューを同時にアクティブにせず、負荷テストを繰り返します。TTFB、P95/P99レイテンシー、リクエストごとのクエリー、キャッシュヒットレート、CPU/IO値などのメトリクスを記録します。中央値とP95が下がり、エラーレートが下がり、分散が小さくなったときが、私にとっての本当の勝利です。ほとんどすべてのWordPressプロジェクトにおいて、この方法はWordPressのクエリキャッシュが分散を増加させ、中央値エラーレートを減少させることを示しています。 応答値 悪化した。

チューニング・プレイブックしきい値とチェック

ヒット率生産的なトラフィックで～60%のオブジェクト・キャッシュ・ヒット以下では、ほとんど意味がない。その後、私は一貫して非アクティブにし、再度測定している。.
Redisのレイテンシー>ローカルの中央値1ミリ秒以上は多すぎる。サブミリ秒はUNIXソケットと短いパイプラインで達成できる。.
DBの待ち時間ライジング スレッドランニング 負荷が大きくなると、まずインデックスやクエリーをチェックします。.
分散私にとっては、P95が下がることの方が、中央値の統計が良くなることよりも重要なことなんだ。.
無効試合内容や価格が更新されるたびに、どれだけのキーが削除されるかを観察しています。大幅な削除はアンチパターンです。.
ウォームアップデプロイ/ページパージの後、重要なルート（スタートページ、カテゴリー、チェックアウト）を自動的にプリウォームする。.

プラグインとの互換性とリスク

拡張機能の中には、キャッシュキーを上書きしたり、トランジェントを早くクリアしすぎたり、必要なキャッシュキーを無視したりするものがある。 フック, これはエントリーの孤児化を招く。マルチサイト環境では、より多くの書き込みイベントが並行して発生し、無効化がより頻繁に発生するため、問題がより顕著になります。ダイナミックプライス、バウチャー、ショッピングバスケットのフラグメントを使用するEコマースワークフローは特に敏感です。そのため、私はプラグインを徐々に無効化し、明確な測定ポイントで検証することで、キャッシュの問題を切り分けます。アドオンがクエリーキャッシュを必要とする場合、私はそれを使わずに、脆弱性なしで動作するソリューションを選択します。 中間層 はクリーンに機能する。.

運用セキュリティ：ロールバックとメンテナンス

私はキャッシュの変更をロールバック可能にしておく。つまり、オブジェクトキャッシュとページキャッシュの機能フラグ、別々の設定ファイル、そして緊急時のためのチェックリストだ。負荷がかかった状態で何か問題が発生したら、まずクエリ/オブジェクト・キャッシュを引き出して、ページ・キャッシュとOPcacheを動作させる。その後で

フラッシュターゲット 影響を受けるキーだけを削除し、Redis全体を空にしない。.
WP-CLIを使用する:
```
wp キャッシュフラッシュ
wp transient delete --all
    
```
事前に測定基準を保存しておき、再度測定する。.
ログのローテーション と遅いクエリ・ログをキャッシュ制御の代わりに使用する。.

簡単な要約：私が雇うものとその理由

WordPressのクエリキャッシュが無効になってしまうので、キャッシュをオフにしています、, レイテンシー と矛盾が理論上の利益を食いつぶしてしまう。その代わりに、私はページキャッシング、OPcache、クリーンなデータベース作業に頼っている。Redisは、明確なホットスポットがあり、十分なRAMが利用可能な場合に選択的に使用します。よく構造化されたクエリ、強力なホスト・リソース、そしてHTMLキャッシングが、すべてのサイトに必要な穏やかで高速なレスポンスを提供するのです。このようにして、パフォーマンスを予測可能に保ち、ユーロのサーバーコストを節約し、どんなクエリー・キャッシュでも確実に阻止できないエラー・パターンを回避しているのです。.