web-dev-qa-db-ja.com

Get_option（）はget_transient（）にアクセスするより速いですか？

今日は、オプション、カスタムテーブル、トランジェントからキーにアクセスする際の速度の違いを調べるために、自分のデータベースをテストします。テストは1000回実行しましたが、1000回のget操作を実行するのにかかる時間は次のとおりです。

  1. get_transient() 0.0245秒
  2. get_option() 0.0068秒
  3. カスタムテーブルから簡単な選択操作0.65秒

また、このテスト中にトランジェントが期限切れになっていないことも確認しました。問題は、get_option()がget_transient()より速いのか、それともテストで何かがめちゃくちゃになったのかです。オプションのキャッシュによるカスタムテーブルの遅延は、WordPressのデフォルトですか？また、オプションはトランジェントのような異なるキャッシュプラグインによってもキャッシュされますか？

plugin-developmentcacheoptionstransientget-option
8
learning_13

今日は、オプション、カスタムテーブル、トランジェントからキーにアクセスする際の速度の違いを調べるために、私のデータベースをテストしました。テストは1000回実行しましたが、1000回のget操作を実行するのにかかる時間は次のとおりです。

Optionsテーブルはほとんどのシステムでオプションとトランジェントの両方に使用され、インデックスが追加されて最適化されていることに注意してください。だからそれは公正な比較ではありません

get_transient（）0.0245秒get_option（）0.0068秒カスタム表からの単純な選択操作0.65秒

これもまた不当な比較であり、autoloadオプションが設定されているオプションは、早い時期に単一のクエリでadvancedでロードされます。そのため、get_optionはWP_Cacheから引き出されているので、オプションは既に取得されています。

また、このテスト中にトランジェントが期限切れになっていないことも確認しました。

これは通常のシステムでは一時的な検索に影響を与えないはずです。結局のところ、検索されるまで期限切れになっているかどうかはわかりません。

問題は、get_option（）がget_transient（）より速いのか、それともテストで何かがおかしくなったのかです。

場合によります。

オプションのキャッシュによるカスタムテーブルの遅延は、WordPressのデフォルトですか？

非常に可能ですが、選択にかかる時間がクエリとテーブルの設計に大きく左右されます。

また、オプションはトランジェントのような異なるキャッシュプラグインによってもキャッシュされますか？

はい、WP_Cacheが使用されます。これは、リクエストの残りのためにそれをメモリに保存します。

再現性

これらはすべてWP_Cacheを介してキャッシュされるので、2回目に要求したときには、DBは関与しません。

可変性とそれは依存

これはすべて共通の基礎を仮定しています、しかしオブジェクトキャッシュはどうでしょうか？

MemcacheDインスタンス、またはRedisインスタンスを紹介しましょう（十分に構築されたサイトでは、特にVarnishセットアップのようなものがない限り、それらをページキャッシングに使用する場合は非常にパフォーマンス上の利点があります）。

今、私たちは新しい状況にあります。

  • データはRAMに保存され、DBから取得されるとプライミングされ、アクセス時間が劇的に短縮されます。それでも変数よりは遅いが、データベースクエリよりはかなり速い
  • 多くの新しいデータがWP_Cacheに格納されていますが、通常はそうではありません。例えば。 WP_Postオブジェクト、post metaなど
  • WP_Cacheはリクエストをまたいで持続します
  • MemcacheDなどは期限切れの過渡現象などを排除することができます

だから今トランジェントとオプションは同じアクセスコストを持っています。それらはすでに近くにありましたが、今ではごくわずかなものであり、要求が出されたときのCPU負荷ともっと関係があります。

だからパフォーマンスのために私はトランジェントやオプションを使用する必要がありますか？

それは疑問に思うべき価値のある質問ですが、答えはその差はごくわずかで、誤差の範囲内です。

its not that simple 

だから、マイクロ最適化をやめる、それらは同じ記憶媒体だ、そしてこれはあなたの時間の価値がない

  • サイト全体のものを保存する必要がある場合はオプションを使用してください
  • 一時的にトランジェントを使用して、計算にコストのかかるものを一時的に保存します。

パフォーマンスに基づいて一方を選択するのは意味がありません。意味のある違いはありません。

大幅に節約できるように最適化するには、はるかに良いことがあります。投稿クエリでメタの代わりに分類法を使用し、__notスタイルのパラメータを使用しない、オブジェクトキャッシュのインストール、ページあたりの投稿数の削減、リモートリクエストの回避など

カスタムテーブルについてはどうなりますか...

いいえ、オプションテーブルはすでに最適化されています。カスタムテーブルを使用すると、オペレーションをWPキャッシングシステムの外部に移動するだけなので、独自のテーブルを作成する必要があります。

14
Tom J Nowell

オブジェクトのキャッシングが見つからない場合、get_transientはget_optionを2回、または有効期限の間隔と値のために1回ずつ呼び出すため、それほど速くなることはありません。

get_optionのパフォーマンスそれ自身は、そのオプションが "自動ロード"（デフォルト）であるかどうかに影響します。すべての自動ロードされたオプションは、DBに対する1回の要求で取得され、メモリキャッシュに格納されます。したがって、たとえ別のオプションに対するものであっても、get_optionを呼び出す回数にほとんど影響はありません。

DBに直接アクセスすると、すべてのキャッシングやその他のパフォーマンスの向上を回避できます。スマートロジックを自分で実装しない限り、遅くなることが予想されます。

それでも、あなたのテストが良いテストであるかどうかはわかりませんが、パフォーマンスに気を配っているかのように、データアクセス時間をより近づけるオブジェクトキャッシュシステム（および関連するプラグイン）を使用することになります。そしてもちろんあなたがあなた自身のDBテーブルを使うことに決めたなら、あなたはあなたのアクセスAPIをオブジェクトキャッシングメカニズムと統合するべきです。

4
Mark Kaplun