web-dev-qa-db-ja.com

WP Transientsを使用して、プラグインの外部データを最適/正しい方法で保存していますか?

私は時々取得される外部データに依存するプラグインを開発しています。速度を上げるために、受信したデータをキャッシュし、10分または15分間隔で更新したいと思います。

外部サーバーもそのような間隔でデータを更新するだけなので、これは大きな問題にはなりません。

しかし、データが既に存在するため、一方では外部サーバーからかなりの負荷がかかり、ローカルサイトの速度も向上すると思います。

最初は、WP Transientsが最適な方法であると確信していましたが、それについてはもうわかりません。多くのプラグインが独自のテーブルを使用してデータを保存していることを常に見てきましたが、Transients APIを介して外部データを_options- tableにプッシュするべきか、それとも専用のテーブル構造がこの場合により適しています。

Transientsまたはその逆でテーブルを使用する際に、客観的で測定可能なポイントはありますか?

更新1:データは、地域のコンテキストを持つXMLのような構造化データです。そのため、ユーザーは理論的には数十のデータセットを取得する必要があるかもしれませんが、多くのデータセットを取得することはおそらくないでしょう。また、「都市データセット」や「エリアデータセット」のように、サーバー側に取得できる「結合された」データセットがあります。

(不明な点があれば質問してください。)

1
flomei

取得しているデータが1つのインスタンスだけ、または多くても少数のインスタンスである場合は、Transients APIがその役割を果たします。覚えておいてくださいそれはまたあなたのための自動満了を処理します。

データが潜在的に無制限の(または少なくとも中規模以上の)インスタンス数になる可能性がある場合、特に取得する正しいエントリを見つけるためのわずかに複雑な方法がある場合(IDだけではない) 。

そうは言っても、3番目の可能性のある選択肢があります。それはファイルシステムです。あなたはwp-contentのサブフォルダのファイルにシリアライズ/ jsonifiedデータを格納することができます。問題のデータが事実上公開されており、少しでも保護される必要がないという条件で、これはもちろんあります。

2
Doug Wollison

10分または15分間隔で更新する

トランジェントは作成するのにコストがかかるので、10〜15分ごとに作成してフラッシュするのは本当に悪い考えです。トランジェントは、長い期間にわたって小さなデータを保持するのに役立ちます。私は常に過渡現象が一日一回以上洗い流されて作り直されるべきではないと信じています。私は30日間トランジェントを設定して、新しい投稿を公開したり用語を更新するなど、何かが起こったときにのみそれらをフラッシュする傾向があります。

トランジェントは、100個の投稿オブジェクトを格納するような大量のデータを保存することも目的としていません。私の答えをここで確認 して 、一時的な使用方法を確認できます。完全なwp_postsテーブルの代わりにソートされた投稿IDの配列を格納しただけです。一時的なものであるため、ページごとに1つずつdb呼び出しを行うことになりますが、ソート処理によって、メモリ使用量を大幅に節約できます。

私はあなたの状況でこの外部データを扱うために本当に新しいテーブルを検討するでしょう。しかしながら、これはデータを保存し処理するためにあなた自身のCRUDプロセスを書くことをあなたに要求するでしょう。あなたはおそらく外部データをキャッシュするためにあなた自身のキャッシュシステムを構築することができますが、それは完全にあなた次第です。

あなたが飛び込んであなた自身のテーブルを作成する前に、あなたは以下の質問に対する @ toshoの答え を読むべきです

1
Pieter Goosen