ワードプレス

オブジェクトキャッシュがWordPressを遅くすることがある理由

多くの管理者は オブジェクト・キャッシュ そして、なぜページの反応が遅くなったり、クエリがハングアップしたり、502エラーが発生したりするのか不思議に思うことでしょう。このような技術的な理由、キャッシュが機能しなくなる原因、そしてキャッシュの設定方法について説明します。.

中心点

過密オートロードされたオプションやトランジェントによって、拒否やタイムアウトが発生する。.
コンフリクト Redis、Memcached、プラグインの間で、機能が遅くなる。.
誤った解釈 のサイトヘルスは、不必要なインストールにつながる。.
無効化 と断片化により、古いデータがRAMに長く留まり続ける。.
役割オブジェクト・キャッシュはページ・キャッシュを置き換えるものではない。.

オブジェクトキャッシュが遅くなることがあるのはなぜですか？

オブジェクトキャッシュはデータベースの結果をRAMに保持しますが、高速化されるのは ヒット率 は高水準を維持し、メモリはクリーンに管理されます。オートロードされたオプションやトランジェントが限界までキャッシュを満たすと、エンジンは新しいエントリーを拒否し、WordPressはデータベースにフォールバックする。これは、サーバーが最初にキャッシュにクエリを実行し、次に失敗し、クエリを再実行し、無駄に再度保存しようとして終わる可能性があるため、待ち時間が増加します。1オブジェクトあたり1MBや約800KBのバッファといったハードリミットがあるプラットフォームでは、パフォーマンスが急激に低下する。そのため、私はPHPやデータベースを調整する前に、まずエントリーのサイズと数をチェックします。.

各キャッシュクエリのオーバヘッドは、たとえエントリが存在しないとしても、次のような影響を与える。 応答時間 を使用する必要があります。繰り返しのDBクエリが少ないサイトでは、キャッシュはほとんど何のメリットももたらさない。動的なページやユーザー固有の要素が多ければ多いほど、キャッシュの設定は慎重になります。明確な無効化ルールがなければ、古い値が残り、バックエンドとライブページで混乱を引き起こします。書き込み、期限切れ、クリアのきれいなプロセスは、物事を高速に保ちます。.

典型的な設定ミスとコンフリクト

複数のプラグインが オブジェクトキャッシュ.php で上書きされる。すると、Redis Object Cache Proのような統合機能が静かに停止し、WordPressは正常に動作しているように見える。Redisは実際にはアクティブであるはずなのに、ツールに高度な統計や警告が表示されないことから、私はこれを認識することができます。また、サーバーにはローカルプロセス用のAPCuがあるにもかかわらず、Site Healthで永続キャッシュがないという誤解を招くような表示もよく見かけます。私は新しいプラグインをインストールする前に、既存のキャッシュの状況を整理し、バックエンドを1つだけにします。.

Redisのパラメータやネットワークのレイテンシが正しくないことも、すべてのRedisに適用できるブレーキです。 オペレーション を追加した。RTTの高い別のホストのRedisは、たとえデータベースがローカルで素早く応答したとしても、Object Cacheをすぐに時間の無駄にしてしまう。これに加え、長すぎるTTLが設定され、古いコンテンツを保存している。ユーザーは、私がとっくに変更をライブに切り替えているにもかかわらず、何分間も古い製品価格や翻訳文字列を見ることになる。接続、名前空間、有効期限を素早くチェックすることで、トラブルシューティングに何時間も費やす必要がなくなります。典型的なRedisの設定ミス一緒にね。

オートロードされたオプションとトランジェントをクリーンに保つ

wp_options テーブルには トラップ プラグインが大量のデータをオートロードとしてマークするとき。WordPressはページリクエストごとにこれらの値を一度にロードするため、オブジェクトキャッシュに巨大な文字列がフィードされる。サイズがバッファの制限を超えると保存に失敗し、サーバーは読み込み、拒否、再読み込みの非効率的なループに入る。そのため、オートロードされるデータは800KB以下に抑え、大きなブロックはオートロードされないオプションや別のテーブルに保存するようにしている。トランジェントが古くなったり、更新中に有効期限が切れたりしない場合は、定期的に削除しています。.

502エラーが発生した場合、私は一時的にその機能を停止する。 キャッシュ バックエンドで、オートロードのオプションを減らし、クリーンアップの後だけキャッシュを再アクティブ化する。これを行うために、私は分析ツールを使い、長いリダイレクトリスト、統計オブジェクト、セッションの残骸など、上位の消費者を調べます。最初の読み込みに絶対に必要でないものは、積極的にすべてクリーンアップします。その後、ロード時間、データベースクエリ、キャッシュヒット率を再度測定します。これらの主要な数値が正しい場合にのみ、シャードサイズやプリロードなどの微調整を開始します。.

オブジェクトキャッシュとページキャッシュ：正しい役割

私は次の2つを明確に区別している。 ページキャッシュ とオブジェクト・キャッシュは、どちらも異なる問題を解決するからです。Page CacheはHTMLページ全体を配信し、PHPとデータベースをほぼ完全に保存します。一方、Object Cacheは、PHPが動作しているときに、繰り返し実行されるフラグメントとオプションを高速化します。ブログやパーソナライズされたコンテンツのないページでは、通常Page Cacheが最大の効果を発揮し、Object Cacheはほとんど役に立ちません。Page Cacheが強みを発揮するのは、ショップ、フィルター、検索機能、多くのDBアクセスだけだ。ページキャッシュとオブジェクトキャッシュ実用的な方法で。.

従って、私はまず より完全な オブジェクトキャッシュを変更する前に、ページキャッシュをアクティブにしています。コールドスタート時のレスポンスタイムが600ミリ秒を下回る場合は、サーバーが正常に動作しており、オブジェクトキャッシュが微調整を行っているに過ぎないことを示しています。ページキャッシュがない場合、オブジェクトキャッシュは症状を緩和しますが、CPUは負荷がかかったままです。その場合、すべての訪問者が再びPHPスタックを起動させるため、ページのスケールが悪くなります。正しい順序はコストを節約し、トラフィックのピークに対する弾力的な予備を作ります。.

モニタリングと測定：正しい診断

セッティングを変更する前に プレゼントリクエストごとのクエリー、キャッシュヒット率、RAMの使用率、平均応答時間。ホットパス、つまりキャッシュに適したクエリの繰り返しと、オーバーヘッドを発生させるだけの単発のクエリをチェックする。実際には、オブジェクトキャッシュなし、ローカルのAPCu/Redis、リモートのバックエンドの3つのシナリオを比較します。これにより、遅延の原因がネットワークにあるのか、キャッシュの書き込みに失敗が多いのか、PHPスタックにあるのかを素早く認識することができる。変更のたびにこれらの測定を繰り返すことで、単なる直感ではなく、信頼できる数値を得られるようにしている。.

これは、最も一般的なエラーのパターンと対処法を素早く分類するのに役立つ。 テーブル 日常生活の中でどの症状がどの原因を指し示しているのか、どの対策を優先するのかを示してくれる。ログファイルに深く入り込む前のチェックリストとして使っています。これにより、エスカレーションの時間を節約し、サイトをより迅速に復旧させることができます。ケース例は、典型的なインシデントの大部分をカバーしています。.

問題	原因	ソリューション
ログイン後の502エラー	バッファオートロードされたオプションによってオーバーロードされる	オートロードされたデータを800KB以下にする。
Redisの機能の欠落	object-cache.phpが他のプラグインによって上書きされる	競合を排除し、正しいファイルをアクティブにする
更新されたにもかかわらず古いコンテンツ	キャッシュの無効化低調	ターゲットパージ、TTLチェック、ライトスルー無効化
重複クエリが多い	ヒットしない、キャッシュ・キーが正しくない	キーの標準化、クエリの重複排除

現場からの素早いチェックと指示

最初の診断のために、意味のある数字がいくつか必要です。まず、データベースに直接あるオートロードされたオプションのサイズから始めます：

-- オートロードされたオプションのサイズを決定する
SELECT SUM(LENGTH(option_value)) AS bytes, COUNT(*) AS items
FROM wp_options
WHERE autoload = 'yes'；

-- 最大のオートロードオプションを見つける
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 20；;

期限切れのトランジションが残っていれば、それを整理する：

-- 期限切れのトランジションを処分する (バックアップをとってから慎重に!)
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
  AND option_name NOT LIKE '_transient_timeout_%'
  AND EXISTS (
    SELECT 1 FROM wp_options t
    WHERE t.option_name = CONCAT('_transient_timeout_', SUBSTRING_INDEX(option_name, '_transient_', -1))
      AND t.option_value < UNIX_TIMESTAMP()
  );

DELETE FROM wp_options
WHERE option_name LIKE '_site_transient_%'
  AND option_name NOT LIKE '_site_transient_timeout_%'
  AND EXISTS (
    SELECT 1 FROM wp_options t
    WHERE t.option_name = CONCAT('_site_transient_timeout_', SUBSTRING_INDEX(option_name, '_site_transient_', -1))
      AND t.option_value < UNIX_TIMESTAMP()
  );

Redisでは、拒絶や退去が起きていないかチェックする：

# 基本概要
redis-cli INFO stats | egrep "evicted_keys|keyspace_misses|keyspace_hits"
redis-cli INFO memory | egrep "used_memory_human|maxmemory|fragmentation_ratio"
redis-cliのCONFIG GET maxmemory-policy

Memcachedの場合、統計はスラブ・プレッシャーとアイテム・サイズの情報を提供します：

エコー統計｜nc 127.0.0.1 11211
echo stats slabs | nc 127.0.0.1 11211
echo stats items | nc 127.0.0.1 11211

私はAPCuを集約されたメトリクスで監視している：ヒット率、フラグメンテーション、占有キャッシュ、エントリー数です。これにより、エントリーが大きすぎるか、TTLが欠落しているためにクリアされないかどうかがよくわかる。.

シリアライザー、圧縮、ネットワークの詳細

の選択である。 シリアライザー と圧縮がサイズと速度を決定します。PHP のシリアライザはより大きな値を生成しますが、汎用的です。バイナリシリアライザは RAM と CPU を節約しますが、設定によっては互換性が低下します。圧縮は、大きくて繰り返しの多い構造（タクソノミーマップなど）には有効ですが、非常に小さなオブジェクトには有効ではありません。私は圧縮を選択的に有効にしており、個々のバックエンドの1MBの制限を回避できるのは、やみくもな圧縮ではなく、巧妙な分割だけであることを認めている。.

同じホスト上で、私は可能な限り、次のものに頼っている。 Unixソケット これにより、レイテンシーとシステム・オーバーヘッドを節約できる。Redisが外部にある場合、私はRTTと変動するパケットのランタイムをチェックする。RTTと変動するパケットのランタイムをチェックする。得る/セット は負荷がかかると増えていく。持続的接続はセットアップのオーバーヘッドを減らし、パイプラインは一連のオペレーションを助ける。同時に、過度にアグレッシブなタイムアウトが不必要な再接続の嵐を招かないようにしている。.

キャッシュの大暴走：猛攻を制す

よく見落とされるパターンがある。 キャッシュスタンピード高価なキーが期限切れになると、複数のプロセスがそのギャップに気づき、同じデータを同時に再生成する。その結果、負荷がピークに達し、時折タイムアウトが発生する。私は3つの戦術でこれを軽減している：

ジッター TTLについて：キーが同時に傾かないように、固定の300秒ではなく、240～360秒をランダムに使っている。.
ソフトなインスピレーション一つのプロセスが再生を引き継ぐ間、エントリーは短時間の „オーバーラン “を許される。.
錠前高価なリビルドの場合：生成の前に短いロックキーをセットする。もし失敗したら、古い値をもう一度配信し、後で再試行する。.

これは、アクセス数の多いページがキー生成を再開しても、レスポンスタイムが安定していることを意味します。ショップページでは、フィルターや検索結果で特に顕著です。.

APCu、Redis、Memcachedの運用について

3つのバックエンドはすべて 特殊性:

APCu はプロセス単位となります。これによりアクセスは非常に高速になりますが、 PHP FPM ワーカープロセス間でエントリが共有されることはありません。フラグメンテーションは、適切な TTL、適度なエントリサイズ、そして十分な shm_size をチェックしている。CLIスクリプトでは、ウォームアップジョブがFPMのキャッシュ領域を遅くしないように、効果が必要な場合のみ、意図的にAPCuを有効にしている。.
メムキャッシュ はスラブで機能する。非常に大きなオブジェクトは、それに対応する大きなクラスで終わらせなければならない。もしこれらのオブジェクトが少ないままだと、他のスラブに空きメモリがあるにもかかわらず、拒否されることになる。アイテムのサイズを最大制限値以下にし、いくつかのキーに分割することで、この行き詰まりを避けることができる。.
レディス は柔軟だが maxmemory-policy は、どのキーがプレッシャーにさらされるかを決定する。私は、ポリシー依存の名前空間とTTLを好むので、立ち退きが „永遠の “設定データにぶつかることはない。AOF/RDBの永続化にはCPUとI/Oがかかる。純粋なキャッシュ操作では、意識的に計算するか、遅延フリーを使用してブロッケードを回避する。.

ホットデータとコールドデータを区別することは重要である：カタログとナビゲーションのフラグメントにはより長いTTLが与えられ、つかの間のユーザー・コンテキストは短時間生きるか、完全に外に残る。こうすることで、キャッシュは関連性を保ち、自ら消去される。.

フラッシュ戦略、名前空間、マルチサイト

„「かつて すべてを洗い流す と良い “ことはめったにない。別のプロジェクトが同じRedis上で動いていたり、インスタンスが複数のステージを共有していたりする場合、これは本番上のリスクとなる。私は 名前空間 と接頭辞ベースのパージ。WordPressでは、DBプレフィックスとプロジェクト固有のキープレフィックスによって分離を確保しています。ステージング／ライブの場合は、ライブのキーが誤って落とされることがないように、別のデータベースか固有のプレフィックスを使用している。.

マルチサイト・セットアップでは、ブログIDはキー戦略の一部である。これにより、サイト間の跳ね返りを防ぎ、サイトごとに的を絞ったパージが可能になる。ドメインを移動する際には、移行経路を計画する。ドメイン・コンポーネントを含むキーは、孤児となった新旧の組み合わせに陥るのではなく、制御された方法で再構築しなければならない。.

データ構造、断片化、RAMの制限

オブジェクトキャッシュの勝利構造TTLが明確で、小さく、明確に定義されたキーは、効率的に管理できる。巨大な配列やオブジェクトを1つのエントリーとして保存すると、断片化やメモリ損失のリスクが高まる。新しいエントリーは、メモリ全体が空いているにもかかわらず、既存の隙間に収まらなくなってしまう。そこで私は、大きなチャンクをいくつかの小さなキーに分割し、それぞれ独立して実行できるようにしている。こうすることでエラー率を減らし、ヒットの確率を上げることができる。.

メモリ管理は多くの場合、LRU戦略に従っている。 エントリー を最初に削除する。重要なデータをピンで固定したり、適切なTTLで書き込んだりしないと、LRUは負荷がかかると間違ったオブジェクトを削除してしまう。また、オブジェクトの最大サイズもチェックする。RAMの合計がまだ空いているにもかかわらず、エントリーが技術的に大きすぎることがあるからだ。このような制限値は、突然大量のミスが現れるまで、簡単に見過ごしてしまう。そのため、エラー・カウンターやバックエンドの仕様を常に確認する価値がある。.

正しいプラグインの選択とステージング戦略

アクティブなキャッシュ・プラグインの数を考えるローを使用し、ホスティングに合ったバックエンドを使用します。Redisは複数のPHPプロセスでキャッシュを共有するのに適していますが、APCuは高速なローカルアクセスに適しています。ステージング環境では、ライブデータが誤って漏れないように、キャッシュが独自の名前空間を使うようにします。各リリースの前に、私は一貫してページキャッシュとオブジェクトキャッシュを空にし、コールドテストとウォームテストを行います。これにより、顧客に影響を与える前にリグレッションを認識することができます。.

アップデートについては、変更履歴をチェックして、次のような変更がないか確認する。 キャッシュ-キーまたは無効化フック。プラグインが既存のパージメカニズムが認識できない新しいデータパスを使用する場合、まさにここにブレーキが隠されている。そのため、私はアップデート後に短期間で固定したテスト計画を立てる：WooCommerceショッピングバスケット、検索、ログインビュー、翻訳。何かがハングアップしたら、すぐにロールバックしてトリガーを切り分けます。この規律はダウンタイムを節約し、コンバージョン率を守ります。.

WooCommerce、WPML、ダイナミックコンテンツの設定

店舗と多言語主義が増える ダイナミクス したがって、キャッシュの要件も異なります。WooCommerceの場合、私は頻繁に使用されるプロダクトクエリとタクソノミークエリを固定し、ショッピングバスケットとユーザー固有の値は意図的に短くするか、キャッシュから完全に除外します。WPMLでは、同じクエリに多くのバリエーションがあります。言語サフィックスと適度なTTLを使用したキー戦略は、ここで価値があります。また、商品の更新時に確実にパージするフックもチェックしています。これにより、私が更新しすぎることなく、カタログを新鮮に保つことができます。.

フォーム、ダッシュボード、カスタマイズされた価格が必要です。 繊細さ スピードと正しさの比率のために。セッションデータやセキュリティに関連するトークンをキャッシュすることは、魅力的に見えても避けている。その代わりに、高価な読み取り専用のクエリに集中し、無効化パスとTTLを短く保ちます。その結果、正しくセキュアなまま、ページが著しく速くなる。これこそが、賢明なキャッシュが危険なショートカットと一線を画すところなのだ。.

ステップ・バイ・ステップ：502エラーから高速ページまで

オブジェクト・キャッシュを有効にした後、ページが突然 しおれ, 私は計画的に進める。まず、サイトが再び読み込まれるようにキャッシュを一時的に無効化し、object-cache.phpを保存します。それから、オートロードされた最大のオプションを分析し、不要なトランジェントを削除して、合計を限界値よりかなり下まで下げます。次のステップでは、キャッシュを再活性化し、ヒット率とレスポンスタイムを測定し、拒絶がないかログを監視する。それでも問題がある場合は、Redisのパラメータ、TTL、ネームスペースを最適化する。.

個々のページは残る低調, 総滞在時間が最も長いクエリを検索し、重複排除やマテリアライズが可能かどうかをチェックする。オーバーサイズのキャッシュ・オブジェクトをより小さな単位に分解し、更新のターゲット・パージ・フックを設定する。リモートのRedisへのネットワークレイテンシーが目立つようになったら、テストとしてローカルのAPCuかホストに近いRedisインスタンスに切り替えます。私はすべての変更を測定値で文書化し、影響を明確に割り出せるようにしている。このように数値に集中することで、闇雲に突っつくことを防いでいる。.

要約：私が実践的に設定したこと

オブジェクトキャッシュを有効にするのは DB負荷 は測定可能で、繰り返しクエリが存在する。私は事前にページキャッシュを設定し、高負荷が最初に発生しないようにする。それから、オートロードされるオプションを小さく保ち、トランジェントを整理し、明確なTTLを定義します。ショップや多言語サイトでは、サフィックスを使ってキーをきれいに計画し、確実な無効化を保証する。より深く知りたい場合は、コンパクトな入門書であるオブジェクトキャッシュとデータベースのチューニング.

を定期的にチェックしている。 ヒット率, キャッシュバックエンドの平均レイテンシとエラーカウンタ。Site Healthに警告が表示されたら、すぐにプラグインを追加インストールするのではなく、実際の測定値と照らし合わせて検証する。2つのキャッシュ・プラグインが同時に動作している場合は、1つを削除し、1つのシステムをクリーンな状態で稼働させます。1つのオブジェクトにつき1MB、あるいは800KBのバッファといった制限を設けて、キーの分割を意識的に計画する。こうすることで、典型的な罠にはまることなく、オブジェクトキャッシュの利点を活用している。.