web-dev-qa-db-ja.com

Update_post_（meta/term）_cacheの説明

私はいくつかの 10upからのベストプラクティス を読んでいましたが、彼らはWP_Queryでこれら2つのフラグをfalseに設定することに言及しています（あなたが問い合わせているものによって異なります）：

  • 'update_post_meta_cache' => false：post metaが利用されないときに便利です。
  • 'update_post_term_cache' => false：分類学用語が利用されない場合に便利です。

私は と仮定して それは update_post_caches() のようなものを利用していますが、それが何を意味するのか100％確信さえしていません。これら2つのフラグがWP_Queryで何を意味するのか、そしてそれらがどれほど有用であるかを誰かが説明できますか？ WordPressがどのように物事をキャッシュするかについて私はあまりよく知らないので、より多くの情報がより良いですが、これら2つのフラグに関してよく考え抜かれた答えも受け入れられます。

post-metatermscachecustomizationcore
20
Howdy_McGee

いたるところにオブジェクトキャッシュ

WordPressはデータベースクエリの数をできるだけ減らそうとします。

たとえば、データベースを照会する前にメタフィールドまたは分類フィールドを取得すると、WordPressはそれがすでに照会されてキャッシュに格納されているかどうかを調べ、データベースを照会する代わりにそこから返します。

"キャッシュジョブ"は WP_Object_Cacheクラスとwp_cache_*関数 によって行われます（これらはそのクラスメソッドのラッパーです）。

キャッシュが存在する場所

デフォルトでは、 "キャッシュ"はPHPグローバル変数にすぎません。それはメモリ内にあることを意味しますが、それがすべての要求で消えることも意味します。

ただし、ドロップイン（advanced-cache.phpやobject-cache.php）を介して、このキャッシュを処理するための独自の方法を設定することは可能です。

通常、このドロップインは、特異な要求を「生き残る」ためのある種のキャッシュメカニズムを設定するために使用されます。

このため、WP人の間では、これらは "永続キャッシュ"プラグインとして知られています（たとえバブルの外側にある場合でも、 "cache"と "persistent"という言葉はあまり意味がありません）。

最近人気のある選択肢は Memcached または Redis です。

したがって、「永続キャッシュ」プラグインを使用すると、リクエストごとにキャッシュが更新されるわけではないため、データベースクエリの数を大幅に減らすことができます。

いくつかの例

$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);

上記の2行のコードは、最大で1回のデータベースクエリをトリガします。

実際、カスタムフィールドをクエリすると、その投稿のすべてのフィールドはデータベースから取得され、オブジェクトキャッシュを介してキャッシュされ、それ以降の要求ではdbからではなくキャッシュからデータが取得されます。

分類学用語についても同じことが起こり、WordPressは分類学に関するすべての用語を一度引き出し、その後それらをキャッシュから返します。

オブジェクトキャッシュはWordPressで非常に広く使われています。投稿、メタ値、分類法だけでなく、ユーザー、コメント、テーマデータについても...

WP_Queryがこれらすべてとどう関係しているのでしょうか。

WP_Queryを介していくつかの投稿を照会すると、デフォルトでは、WordPressはそれらをデータベース（またはキャッシュされている場合はキャッシュ）から引き出すだけでなく、引き出された投稿に関連するすべてのカスタムフィールドおよびすべての分類法のキャッシュを更新します。

ですから、例えばWP_Queryを介して投稿をループしながらget_the_terms()やget_post_meta()を呼び出した場合、実際にはデータベースクエリを起動するのではなく、キャッシュから情報を引き出します。

いいですよね。

はい、そうです、しかしそれにはコストが伴います。

WordPressがWP_Queryを介した投稿をプルしたときに行うキャッシュ更新の「魔法」は、メタの場合は update_meta_cache 、分類法の場合は update_object_term_cache で発生します。

これらの関数のソースコードを見ると、WordPressが各関数内でただ1つのdbクエリを実行するだけでなく、多くの処理も行うことがわかります。たとえば、update_object_term_cacheには 7のネストされたforeach ...があります。分類法が多く、1ページあたりの投稿数が多い場合、これはあまりパフォーマンスが良くありません。

これらのWP_Query引数について、最後に

falseに設定されたときに'update_post_meta_cache'と'update_post_term_cache'がすることは、WordPressがそれぞれカスタムフィールドと分類法のためにキャッシュを更新するのを防ぐことです。

その場合、カスタムフィールドまたは分類法が初めてクエリされると、データベースクエリがトリガされ、データがキャッシュされます。

それはトラブルの価値がある？

いつものように、答えはそれによって異なりますです。これらの値をfalseに設定するほとんどの場合は、不要な処理や不要なデータベースクエリを防止し、カスタムフィールド/分類法の用語が初めて必要になったときにキャッシュを更新するので、良い選択です。

ただし、ループ中にget_post_meta()を1回呼び出して、投稿でサポートされている分類のすべて（または大部分）についてget_the_terms()を呼び出す場合は、キャッシュの更新がトリガーされ、実際には実行されない可能性があります。これらのクエリ引数をfalseに設定することには利点があります。

28
gmazzap

ここでの主な関心事はupdate_post_caches関数です。 WP_QueryがDBからすべての投稿を取得した後に呼び出されます。通常、最初に投稿を表示したいのはそれらを表示することです。これは通常メタデータに基づいて用語と何かを表示することを意味します。そのためWP_Queryはデフォルトで返された投稿に関するメタデータと用語データをDBに問い合わせます。そしてそれをキャッシュ*に格納します。この情報はWP_Queryから返されるデータでは明示的に利用できませんが、特定の投稿の用語とメタ情報を取得するために関連するAPIを呼び出すときには、既にメモリで利用可能であり、新しい情報を送信する必要はありません。 DBに問い合わせます。

これにより、ワードプレスでは、各投稿ごとにリクエストを送信するのではなく、すべての投稿の情報を取得するためのリクエストを1つだけ送信することで、DBへのリクエスト送信に関連するオーバーヘッドを削減できます。

現時点では、キャッシュを更新したくない場合の些細な例を見つけることはできませんが、すべての投稿のタイトルのリストがほしい場合は、些細なことかもしれません。そのためには、用語やメタデータは必要ありません。

* cache - ここで最も重要なのは、オブジェクトキャッシュプラグインをアクティブにしなくても、WPがDBから取得したものすべてを格納するメモリベースのキャッシュです。オブジェクトのキャッシュがある場合は、情報もそこに格納されます。

3
Mark Kaplun