階層的分類法とupdate_meta_cache関数

Question

私はカスタム階層分類法を持っていますが、最近カスタムフィールド（用語メタ）を持つ用語の束（15k +）をインポートしました。

それ以来、分類ページの追加/編集ページとCPT（このタクソノミーが割り当てられているページ）のページは非常に遅くなりました。

私はこの問題をすべての負荷でこれらのページで発生するupdate_meta_cache関数にトラッキングしました。クエリモニタの出力のスクリーンショットです：http://imgur.com/a/FX188

これは「フラット」な（非階層的な）分類では起こりません。私は220k +の用語で別の平らなタクソノミを持っていて、何も減速していません。 WPがすべてのページのすべての条件のメタキャッシュを更新する理由は何ですか？この動作を制御/無効にするためのきちんとした方法はありますか？

UPDATE私はそれを行うにはひどいことだけど、私は先に行って、/wp-includes/taxonomy.php編集した - 私は、あるライン1370コメントアウト：

今

return update_meta_cache('term', $term_ids); 

分類ページに管理者ははるかに高速です - http://imgur.com/a/7MJSg

ちょうど比較する - フラットタクソノミのページはかなり速いです - http://imgur.com/a/lcUOM - しかし、2 - 何秒の時間が十分です。

しかし、CTPのページはまだ非常に遅いです - http://imgur.com/a/tFCAr - DB時間はまだ小さいです。どのようなアイデアを与える？なぜ私はまだ18秒のページ生成時間を得ていますか？私は、違いがどのようなものになるのでしょうか？

Answer 1

はいこれは、階層分類で重大なパフォーマンスの問題です。これは既知であり、ある時点で修正する必要がありますが、これはWPがキャッシュをどのように処理するかで決まります。

（あなたが言ったように、それは単一のクエリだ、フラット階層分類学上の）問題は、すべての用語そのWPクエリではありませんが、それを得るためにためherarchical分類学上のすべての用語をクエリを実行する必要があること子どもという言葉。 WPがすべてのget_termコールで照会する必要はないが、この状況では悲惨な結果を招くため、この動作は最初のケースではきちんとしている。 - 「永久」のキャッシュを持つことにより、すべてのページのロードの分類をキャッシュW3 Total Cacheように正しく設定されたキャッシュのプラグインがないようにするのに役立ちます

• がキャッシュプラグインを使用します。

  ここでは3つの可能な解決策があります。これは完璧ではありませんが、これは通常私が解決する解決策です。

• は、手動でキャッシュの引数を使用してWP_Query要求ごとのキャッシュを無効にします。

  'update_post_meta_cache' => false, 
  'update_post_term_cache' => false 
  

  これは、フロントエンドのクエリのために主に役立ちますので、私はそれはあなたのケースでは良い解決策だとは思いません。

• 階層分類を使用しないでください。
  いいえ、真剣に。それほど多くの用語を持っているなら、あなたの分類法を扱うための他の解決策を探すべきです。たとえば、Woocommerceは、製品の属性についてこのパフォーマンスの問題を回避するスマートな仕掛けを使用します。すべてのレベル0の用語は、特別なクラスと組み合わされた分類法です。これには設定作業が必要ですが、それは良い解決策です。

私はこのパフォーマンスの問題in the Wordpress core trackerにはいくつかの参照を探したが、それは、このためのオープンチケットが存在しないようです...たぶん、あなたはあなたのデータのものを開くことができます。