アンチパターン: 256 KB 超のデータをキャッシュに保存する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

現在、Apigee と Apigee ハイブリッドのドキュメントを表示しています。
Apigee Edge のドキュメントはこちらをご覧ください。

Apigee ではランタイム時にデータがキャッシュに保存されるので、永続的かつより速くデータを取得できます。

• データは最初に Message Processor のメモリ内キャッシュ（L1 キャッシュ）に保存されます。
• L1 キャッシュは、専用に予約されたメモリ量（JVM メモリにおける割合）を上限とします。
• その後、キャッシュ エントリは L2 キャッシュに留まり、すべての Message Processor からアクセスできるようになります。詳細については、以下のセクションをご覧ください。
• L2 キャッシュには、保存可能なエントリ数に対するハードリミットはありません。ただし、キャッシュに保存可能なエントリの最大サイズは 256 KB に制限されています。256 KB というキャッシュ サイズは、最適なパフォーマンスを実現するための推奨サイズです。

アンチパターン

このアンチパターンは、Apigee 内の現在のキャッシュ サイズ制限を超える場合の影響についてのものです。

キャッシュに保存されたデータのサイズが 256 KB を超えると、次の影響があります。

• 256 KB を超えるデータは L2 キャッシュに保存できないので、各 Message Processor で初めて実行される API リクエストでは、元のソース（ポリシーまたはターゲット サーバー）からデータを別途取得する必要があります。
• 大きなデータ（256 KB 超）を L1 キャッシュに保存すると、プラットフォーム リソースにかかる負担が大きくなります。結果的に、L1 キャッシュ メモリがすぐに満杯になり、他のデータを保存するための容量が少なくなります。このため、望ましい頻度でデータをキャッシュに保存できなくなります。
• エントリ数の上限に達すると、Message Processor 内のキャッシュ エントリは削除されます。その結果、それぞれの Message Processor で元のソースから再びデータを取得することになります。

影響

• 256 KB を超えるデータは L2 / 永続キャッシュに保存されません。
• 元のソース（ポリシーまたはターゲット サーバー）への呼び出し頻度が高くなるため、API リクエストのレイテンシが大きくなります。

ベスト プラクティス

• 最適なパフォーマンスを得るために、キャッシュに保存するデータを 256 KB 未満に抑えることをおすすめします。
• 256 KB を超えるデータを保存する必要がある場合は、以下を検討してください。
  • 大きなデータの保存に適したデータベースを使用する

    または

  • データを圧縮する

関連情報

• キャッシュの内部