この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

Newer Version Available

This content describes an older version of this product. View Latest

プラットフォームキャッシュのベストプラクティス

プラットフォームキャッシュによって、アプリケーションのパフォーマンスが大幅に向上します。ただし、最適なキャッシュパフォーマンスを得るには、次のガイドラインに従うことが重要です。一般に、多くの小さな項目を別々にキャッシュするよりも、少しの大きな項目をキャッシュする方が効率的です。また、予期しないキャッシュの強制削除を防止するために、キャッシュ制限にも注意してください。

パフォーマンスへの影響を評価する

プラットフォームキャッシュによってアプリケーションのパフォーマンスが向上するかどうかをテストするには、キャッシュを使用した場合と使用しない場合の経過時間を計算します。実行時間については Apex デバッグログのタイムスタンプを使用しないでください。代わりに System.currentTimeMillis() メソッドを使用します。たとえば、最初に System.currentTimeMillis() をコールして開始時刻を取得します。アプリケーションロジックを実行し、キャッシュまたは別のデータソースからデータを取得します。その後で経過時間を計算します。

キャッシュの欠落を適切に処理する

null を返すキャッシュ要求をテストして、コードでキャッシュの欠落が処理されることを確認します。デバッグに役立てるために、キャッシュ操作に関する情報のログ記録を追加します。

または、キャッシュの欠落をチェックする Cache.CacheBuilder インターフェースを使用します。

キャッシュ要求をまとめる

可能ならばキャッシュ要求をまとめます。ただし、キャッシュ制限には注意してください。パフォーマンスが向上するように、個々のキーではなくキーのリストに対してキャッシュ操作を実行します。たとえば、Visualforce ページを呼び出したり、Apex でタスクを実行したりするのに必要なキーがわかっている場合は、一度にすべてのキーを取得します。複数のキーを取得するには、初期化メソッドで get(keys) をコールします。

キャッシュする項目を大きくする

多くの小さな項目を別々にキャッシュするよりも、少しの大きな項目をキャッシュする方が効率的です。多くの小さな項目をキャッシュすると、パフォーマンスが低下し、合計シリアライゼーションサイズ、シリアライゼーション時間、キャッシュコミット時間、キャッシュ容量の使用率など、オーバーヘッドが増加します。

1 回の要求でプラットフォームキャッシュに多くの小さな項目を追加しないでください。代わりに、リストなど、データをより大きな項目でラップします。リストが大きい場合、複数の項目に分割することを検討します。次に、避けるべき例を示します。

代わりに、キャッシュ項目あたりのサイズ制限を超えない、いくつかの妥当な大きさの項目でデータをラップします。

大きめの項目をキャッシュするもう 1 つのよい例は、データを Apex クラスにカプセル化することです。たとえば、個々のデータ項目ではなく、セッションデータをラップするクラスを作成し、そのクラスのインスタンスをキャッシュできます。クラスインスタンスをキャッシュすると、全体的なシリアライゼーションサイズとパフォーマンスが改善されます。

キャッシュ制限に注意する

項目をキャッシュに追加するときには、次の制限に注意します。

キャッシュパーティションサイズ制限
キャッシュパーティション制限に達すると、キャッシュが 100 % の容量に削減されるまでキーが強制削除されます。プラットフォームキャッシュでは、Least Recently Used (LRU) アルゴリズムを使用してキャッシュからキーを強制削除します。
ローカルキャッシュサイズ制限

項目をキャッシュに追加するときには、1 要求内のローカルキャッシュ制限を超えないようにしてください。セッションキャッシュのローカルキャッシュ制限は 500 KB、組織キャッシュは 1,000 KB です。ローカルキャッシュ制限を超えた場合、要求がコミットされる前に項目がローカルキャッシュから強制削除されることがあります。この強制削除によって、予期しない欠落や長時間のシリアライゼーションが発生しかねず、リソースが浪費される場合があります。

単一キャッシュ項目のサイズ制限
個々のキャッシュ項目のサイズは、100 KB に制限されています。項目のシリアライズサイズがこの制限を超えると、Cache.ItemSizeLimitExceededException 例外が発生します。この例外をキャッチし、キャッシュ項目のサイズを削減することをお勧めします。

キャッシュ診断ページを (慎重に) 使用する

使用されているキャッシュ量を判別するには、[プラットフォームキャッシュ診断] ページを確認します。[診断] ページにアクセスする手順は、次のとおりです。
  1. ([ユーザーの詳細] ページで) ユーザーの [キャッシュ診断] が有効であることを確認します。
  2. [プラットフォームキャッシュ区分] ページで、パーティション名をクリックします。
  3. パーティションの [診断] ページへのリンクをクリックします。
[診断] ページには、容量の使用率、キー、およびキャッシュ項目のシリアライズおよび圧縮サイズなど、重要な情報が表示されます。セッションキャッシュと組織キャッシュにはそれぞれ別の診断ページがあります。セッションキャッシュ診断ページはセッションごとにあり、すべての有効なセッションに対するインサイトは提供しません。

診断ページの生成は、すべてのパーティション関連情報を収集する、高コストの操作です。慎重に使用してください。

メモ

高コストの操作を最小限に抑える

高コストの操作を最小限に抑えるには、次のガイドラインを考慮します。

  • Cache.Org.getKeys() および Cache.Org.getCapacity() は慎重に使用します。どちらのメソッドも高コストです。これは、すべてのパーティション関連情報をトラバースして特定のパーティションを探したり、そのパーティションの計算を行ったりするためです。

    Cache.Session の使用は、高コストではありません。

    メモ

  • contains(key) メソッドの後に get(key) メソッドをコールするのは避けてください。キー値を使用する場合は、get(key) メソッドをコールし、値が null ではないことを確認するだけにします。
  • キャッシュは必要な場合にのみクリアします。キャッシュのクリアでは、すべてのパーティション関連キャッシュ空間をトラバースします。つまり、高コストです。キャッシュをクリアした後、アプリケーションは、データベースクエリと計算を呼び出してキャッシュを再生成する可能性があります。この再生成は複雑で広範囲に及ぶことがあるため、アプリケーションのパフォーマンスに影響を与えます。