WordPress オブジェクトキャッシュのヒット率：その意義と適切な目標値

WordPressのオブジェクトキャッシュが保存する内容

仝 WordPress オブジェクトキャッシュ データをキーごとにグループ内で保持します。WordPressが同じ値を再度要求した場合、その処理を改めて実行する代わりに、キャッシュから取得することができます。これには、通常であればデータベースから読み込んだり、再計算したりする必要があるデータなどが含まれます。

組み込みのCore実装は、デフォルトでは リクエスト連動型: キャッシュは、1回のリクエスト中にのみそのエントリを保持します。そのため、その後のページアクセスでは、以前に保存された値に自動的にアクセスできるわけではありません。とはいえ、キャッシュは1回のリクエスト内でも、繰り返しアクセスを回避することができます。

ドロップインにより、コアの実装を 永続的なオブジェクトキャッシュ 置き換える。そうすれば、個々のリクエストを超えて適切なエントリを維持することができます。Redisはバックエンドの選択肢の一つですが、WordPressの必須要件ではありません。他のバックエンドアプローチも可能です。永続的なドロップインを使用した場合でも、特定のグループは引き続き現在のリクエストにのみ適用されることがあります。

トランジェントは、一時的に必要なデータを保存するためのもう一つの手段です。永続的なオブジェクトキャッシュを使用すれば、通常はデータベースに保存されることなく、そこにデータを保存することができます。その有効期限は、保証された最低可用性を示すものではありません。値はそれより早く消滅する可能性があります。 そのため、アプリケーションコードはトランジェントが存在しない可能性を想定し、必要に応じてその値を再生成できるようにしておく必要があります。

後のヒット率の評価において、この区別は極めて重要です。リクエスト中のローカルキャッシュへのアクセスと、外部バックエンドへのアクセスは、必ずしも同じ指標とは限りません。したがって、まず、実際にどの実装が使用されているか、そしてどのデータが永続的に扱われているかを確認してください。

オブジェクトキャッシュとページキャッシュの違い

ページが閲覧されると、 ページキャッシュ すでに生成済みのページレスポンスを返す。そこでリクエストに応答される場合、そのリクエストはキャッシュされていないリクエストのように、同じWordPressアプリケーションパスを経由する必要はない。一方、オブジェクトキャッシュは、アプリケーション内でページレスポンス全体ではなく、個々のキャッシュされたデータを用いて動作する。

一般に公開されている記事ページを想像してみてください。そのページがページキャッシュに保存されていれば、そのまま配信できます。一方、WordPressがそのページを生成する必要がある場合、データへのアクセスが繰り返される際にはオブジェクトキャッシュが役立ちます。これにより実際にどの程度の処理が省略されるかは、リクエストの内容、保存されているエントリ、および実装方法によって異なります。

これは解釈に影響を及ぼします。オブジェクトキャッシュの比率が良好であるということは、単に記録されたキャッシュアクセスを表しているに過ぎません。それだけでは、すでにページキャッシュから完成したレスポンスを受け取っている訪問者の数や、ウェブサイト全体の応答速度がどれほど速いかについては、直接的には分かりません。 ページキャッシュが十分に機能している場合、オブジェクトキャッシュの利点は、とりわけ残りのWordPressリクエストにおいて顕著に現れることがあります。

また、ブラウザキャッシュやOPコードキャッシュも、それぞれ異なる役割を果たしています。ブラウザキャッシュは訪問者の端末にリソースを保持し、PHP OPコードキャッシュはコンパイル済みのPHPコードを保存します。いずれも、オブジェクトキャッシュへの個々のアプリケーションデータの保存や、ページキャッシュからの完全なレスポンスの配信に代わるものではありません。

定数 WP_CACHE これだけではRedisオブジェクトキャッシュは有効になりません。永続的なオブジェクトキャッシュを実現するには、適切な実装と、それがサポートする設定が必要です。複数のレイヤーの連携に関する追加の例については、以下の記事をご覧ください。 AccelerateWP キャッシュエンジン.

ヒットとミスが示すもの

A ヒット 対象のキャッシュレベルで、検索対象のエントリが見つかった場合に発生します。 ミス つまり、そこでは検出されないことを意味します。ヒット率は、ヒット数を、カウントされたすべてのヒット数とミス数の合計で割った値です：ヒット数 ／（ヒット数 ＋ ミス数）× 100。ヒットもミスもない場合、その期間のヒット率は定義されません。

エラーが必ずしも技術的な不具合とは限りません。最初のアクセス時には、エントリがまだ存在しない場合があります。また、有効期限が切れた後も、必要に応じて再取得または再生成されることがあります。重要なのは、具体的な処理の流れにおいて、こうした失敗がどのような影響を及ぼすか、そしてアクセスを再度試みることにそもそも意味があるかどうかです。

WordPressのコアメソッドは、独自の実装においてキャッシュヒットとキャッシュミスをカウントします。 しかし、ドロップインプラグインによってこの実装が置き換えられる可能性があります。そのため、コアの集計方法からは、プラグインの表示が何を計測しているかを確実に推測することはできません。使用しているバージョンについて、その指標がどのアクセスとどの期間を対象としているかを確認してください。

Redisは次のように報告します keyspace_hits そして keyspace_misses Redisのキースペースにおけるキー検索の成功または失敗。また、失敗した EXISTS-この呼びかけはミスとしてカウントされる可能性があります。これ Redisのヒット率 したがって、それは必ずしもWordPressやプラグインの割合とイコールであるとは限りません。

1つのRedisインスタンスが複数のウェブサイトやアプリケーションに利用されている場合、そのカウンターはそれらのアクセス数をまとめて反映することになります。そのため、適切な個別のテレメトリデータがなければ、グローバルなクォータを個々のWordPressウェブサイトに確実に割り当てることはできません。したがって、比較を行う際は、その数値が具体的にどのレベル、どのインスタンスに関するものかを必ず明記しておく必要があります。

測定範囲とアクセスを確実に確認する

測定を行う前に、WordPress がどのオブジェクトキャッシュの実装を使用しているかを確認してください。WP-CLI が利用可能で、WordPress ディレクトリへのアクセス権がある場合は、次のコマンドを実行して、そのディレクトリの読み取り専用インベントリを取得できます：

wp cache type

この結果は実装の分類に役立ちますが、関連するすべてのアクセスが永続的に保存されることを証明するものではありません。WordPressでは、ドロップインがコアキャッシュを置き換えることが可能ですが、一方で個々のグループは永続的ではない場合があります。そのため、使用しているドロップインやプラグイン、およびそのバージョンも記録しておいてください。

具体的なバージョンのドキュメントを参照し、表示されている「ヒット」と「ミス」がどのようなアクセスを含み、どの期間にわたって集計されているかを確認してください。 プラグインのクォータを他の指標と有意義に比較できるのは、測定範囲と集計方法が判明している場合に限られます。特に重要なのは、その表示が単一のリクエストのみを表しているのか、それともより長い期間を表しているのかという点です。

Redis については、接続と権限が確保されていれば、Redis CLI セッションで統計情報やメモリ情報を読み取り専用で取得できます。以下のコマンドには、意図的に認証情報は含まれていません：

INFO stats
INFO memory

を記録する 測定範囲: どのインスタンスまたはノードが照会され、それらは他にどのようなウェブサイトやアプリケーションで使用されているのか？ グローバルなRedisカウンターは、共有されている場合、単一のウェブサイトに容易に紐づけることはできません。情報を共有する前に、機密性の高い運用情報が含まれていないか出力を確認してください。この状況把握のために、フラッシュや負荷テストを行う必要はありません。

Redis CLI にアクセスできない場合は、ホスティングプロバイダーに、利用可能なメトリクスとその適用範囲について確認してください。また、ダッシュボードも、それが同じインスタンス、個々のノード、あるいはすでに集計された値のいずれを表示しているかが明確になって初めて、有用な情報源となります。

区間ごとのRedisヒット率を計算する

Redisの統計情報はカウント値であり、特定の測定期間に関する確定的な結論ではありません。間隔ごとの分析を行うには、以下の値を確認してください。 keyspace_hits そして keyspace_misses その同一インスタンスについて、指定された時間枠の開始時と終了時に測定を行います。測定値が一致するように、両方の時刻と対応するインスタンスを記録しておいてください。

次に、各カウンターについて、終了値から開始値を差し引きます。その インターバルヒット率 は、ΔHits / (ΔHits + ΔMisses) × 100 となります。記号 Δ はそれぞれの差を表します。両方の差がゼロの場合、そのウィンドウではカウントされたルックアップは存在せず、その場合の比率はゼロパーセントとなるのではなく、未定義となります。

これはあくまで説明のための計算例であり、実際の測定結果ではありません。ヒット数が900増え、ミス数が100増えた場合、合計1,000回のルックアップのうち90パーセントが該当することになります。 これは、ページの表示速度が90％向上したわけでも、データベースへのクエリが正確に900回削減されたわけでもありません。Redisはキーのルックアップ回数をカウントしますが、そのアプリケーションにおける重要性は、個々のアクセス状況によって異なります。

検針の合間にいずれかの計量値が減少した場合、この区間における単純な差分計算は有効ではありません。 これは、再起動や統計値のリセットによって発生する可能性があります。測定ウィンドウを最初からやり直すか、式に負の値を代入する代わりに、信頼できる稼働データに基づいて区切り点を設定してください。

ノードが複数ある場合は、まず各該当ノードについて、同じ期間における差分を計算します。次に、ヒット数とミス数を別々に合計し、そこから総合比率を算出します。 個々のパーセンテージ値の加重平均を算出しない場合、ルックアップ回数の少ないノードと多いノードが同じように扱われてしまうため、全体像が著しく歪んでしまう可能性があります。

その際、実際にどのノードが対象となっているか、またそれらが環境内でどのような役割を果たしているかを明確に把握しておいてください。このように算出された総合レートは、選択されたカウンターとそのユーザーのみを表すものであり、それだけでは特定のWordPressオブジェクトキャッシュの割合として集計されるものではありません。

測定記録とRedisの主要指標

ヒットやミスに加え、その他のRedisカウンターも分類の参考になります。ここでも、選択した期間における差異は、単独の合計値よりも意味があります。以下の表では、数値そのものの重要性と、それだけでは裏付けられない結論とを区別しています。

～の増加 expired_keys これは、有効期間やアクセスパターンを詳しく検討するきっかけとなるかもしれません。しかし、有効期限が切れた直後にそのエントリが再び必要とされたかどうかは示していません。同様に、 evicted_keys 設定されたストレージ上限や置換戦略の文脈で検討すべきであり、そこから即座にストレージ容量の増設を結論づけるべきではない。

実用的な 測定記録 時間枠の開始時刻と終了時刻、インスタンスまたはノード、2つのカウンタの差、その合計、および算出された比率を記載してください。また、そのインスタンスが共有されているかどうか、および時間枠の間に再起動やリセットが行われたかどうかについても追記してください。これにより、後々でも測定結果の追跡が可能になります。

対象のリクエストタイプと、それに適したレイテンシ指標、ならびにデータベースの負荷やエラー率を並行して記録してください。例えば、適切なデータが存在する場合は、一般ユーザーによるページ閲覧とログイン済みユーザーからのリクエストを区別してください。 Redisの利用率だけでは、これらのリクエストタイプのうち、どのタイプがヒットによる恩恵を受けたかを特定することはできません。

後での比較のため、期間、ノード、およびリクエストの構成は可能な限り類似しているようにすべきです。また、関連する変更点や明らかなウォームアップ段階についても記録しておいてください。データが欠落している場合や、共通のインスタンスでは割り当てができない場合は、一見正確に見える結論を導き出すのではなく、その制約事項をプロトコルに記載する必要があります。

コールドスタート、オンラインショップ、静的ウェブサイト

再起動やデプロイ後、必要なエントリが一時的に欠落している場合があります。このような欠落はキャッシュの初期化時に予想される現象であり、繰り返しアクセスを行うことで、その後ヒット率が向上する可能性があります。 低温段階と高温段階 これらを個別に検討すべきです。そうすることで、長期的な平均値が、初期費用やその後の推移を覆い隠すことを防げます。

オンラインショップやログインが必要なエリアでは、動的なリクエストが特に注目されます。ページキャッシュは、必ずしもすべてのショッピングカートやアカウントへのアクセスに対応するとは限りません。 そのため、できるだけ類似したリクエストタイプを比較し、ヒット率だけでなく、その応答時間やデータベースへの負荷にも注意を払ってください。Redisのヒット率が高いからといって、それだけでショッピングカートが高速かつ正確に表示されるかどうかは判断できません。

一方、主に静的なウェブサイトの場合、ページビューの大部分はすでにページキャッシュから提供されている可能性があります。そのような場合、永続的なオブジェクトキャッシュは、主にWordPressが実際に処理するリクエストに対して効果を発揮します。したがって、残りのリクエストがキャッシュの恩恵を受けるかどうか、またその効果がウェブサイト全体に及ぶかどうかを個別に判断してください。

Redisを他のウェブサイトやアプリケーションと共用している場合、それらのアクセス数もインスタンスのカウントに含まれます。 適切な個別のテレメトリがない場合、グローバルなクォータを個々のウェブサイトに確実に割り当てることはできません。また、どのノードが計測対象となっているかも記録してください。そうしないと、クォータの変化が、他の利用状況や計測範囲の変更によるものかもしれないからです。

異常な数値やエラーの調査

低い割合は、あくまで観察結果であり、診断ではありません。 初回アクセスが多い、有効期間が短い、あるいはキーの再利用が稀なアクセス分布などが、その原因として考えられます。メモリやキャッシュの設定を調整する前に、リクエストの構成や測定期間に変更がないか確認してください。

カウンター expired_keys そして evicted_keys さらに手がかりとなる指標があります。1つ目は有効期限が切れたキーの数を、2つ目はメモリ制限により置き換えられたキーの数を示しています。これらの数値の差はRedisインスタンス固有のものであり、設定や使用状況に合わせて調整する必要があります。 期限切れのキーが多いからといって、TTLの設定が間違っているわけでも、より長い有効期間に意味があるわけでもありません。むしろ、保存されたデータの最新性を損なう可能性があります。

独自の拡張機能については、 wp_cache_get パラメータ $found 重要：これは、検出された値と保存された値を区別しています false 見つからないエントリについて。グループ関連の操作を行う前には、 wp_cache_supports そのバックエンドが希望する機能をサポートしているかどうかを確認してください。代替となるドロップインは、コアの実装とは異なる場合があります。

警告： 不用意なキャッシュのフラッシュは、意図した以上に多くのエントリやアプリケーションに影響を及ぼし、次の測定結果をコールドスタートによって歪める可能性があります。削除操作を実行する前に、その影響範囲と承認を確認してください。これに関するその他の検討事項として、 WordPressのオブジェクトキャッシュの動作が遅い場合のトラブルシューティング 調査にキャッシュによるオーバーヘッドの可能性も考慮に入れるのに役立ちます。

自分なりに適切な目標値を決定する

90％という一律の最低基準は、信頼性の高い技術的要件とは言えない。より妥当なのは、 地域ごとの目標範囲, 予想されるアクセス分布やアプリケーションへのメリットに見合ったもの。Redisでは、観測された割合をそれぞれのアクセスパターンという文脈で評価することを推奨しています。パーセンテージ値だけでは、WordPressのパフォーマンスを説明することはできません。

まず、期間、測定範囲、アクセス数、および比率を含む、代表的な初期測定値を記録してください。 その際、主要なリクエストタイプの応答時間、データベースの負荷、エラー率を記録してください。コールドスタートは別途区別し、たまたま負荷が低かった時間帯を「通常状態」として扱うのではなく、負荷が低い時間帯と高い時間帯の典型的な違いを考慮に入れてください。

その後、具体的な変更を計画し、承認を得た後は、可能な限りまず適切なテスト環境で検証してください。 その後、同等の期間とリクエストの構成を比較してください。クォータやルックアップ数はもちろん、レイテンシやデータベースの負荷にも変化が見られますか？ これにより、単なるアクセスタイミングのずれと、変更による影響をより明確に区別することができます。

ヒット率が高くても、ごく少数の、特にコストのかかるミスが見えにくくなる可能性があります。逆に、関連性の高い問い合わせに迅速かつ正確に対応できるのであれば、ヒット率が中程度であっても問題にはなりません。 Redisやその他の永続的なバックエンドの運用コスト増は、クォータが改善されたという理由だけで自動的に正当化されるわけではありません。ホスティングのサポート体制、コスト、および想定される障害シナリオも考慮に入れる必要があります。