ウォームキャッシュによって繰り返し発生する Plex リクエストが変わる仕組み
ウォームキャッシュは、いったん取得するのにコストがかかったデータが、より高速なメモリやローカルキャッシュからすでに利用できる可能性があるため、Plexへの繰り返しリクエストの結果を変えます。
この2回目の高速なリクエストは実運用では有用ですが、容量テストを誤解させることがあります。ポスター、メタデータオブジェクト、ファイルシステムのページ、または最近読み取られたファイルは、最初のリクエストと同じストレージ経路を使わずに素早く返される可能性があります。有用な比較では、キャッシュの状態、ワーキングセットのサイズ、メモリ負荷を示し、繰り返し時の速度をサーバーの余裕が無制限であることと取り違えないようにします。
最初のリクエストでは低速なストレージからデータを取得することがある
初回アクセスでは、オペレーティングシステムやアプリケーションがSSD、HDD、またはネットワークマウントされたファイルシステムからデータを読み取る必要がある場合があります。この経路には、要求されたバイトデータをPlexやクライアントに提供する前の、デバイスレイテンシ、ファイルシステム処理、場合によってはメタデータ検索が含まれます。
Linuxは通常、未使用のメモリをファイルデータのキャッシュに利用するため、初回読み取りでページキャッシュにデータが格納されることがあります。必要なページがメモリ上に残っており、アプリケーションが意図的にキャッシュを回避していない限り、後続の読み取りでは物理I/Oの一部を省略できます。
公平なテストを行うには、データが最近アクセスされていない状態から、本当に最初のリクエストとなるものを記録します。サーバーの再起動だけがよりコールドな状態を作る方法だと考えないでください。また、合成ベンチマークを追求するためだけに、本番システムでキャッシュを強制的に追い出すことも避けてください。
繰り返しのリクエストはRAMやアプリケーションキャッシュにヒットすることがある
同じデータが一度リクエストされると、複数の層がより高速に応答できるようになります。オペレーティングシステムはファイルページを保持でき、クライアントはアートワークやインターフェースデータをローカルに保存でき、アプリケーションはリクエストのたびにオブジェクトを再構築する代わりに、生成済みまたは変換済みのオブジェクトを再利用できます。
繰り返し読み取りは、キャッシュされたページがストレージレイテンシを隠すことが最も明確に表れる場面の一つです。これは測定が無効になるという意味ではなく、その結果がバックエンドデバイスのキャッシュなし性能ではなく、ウォームなワーキングセットを示しているという意味です。
Plex固有のキャッシュ動作は、生成された画像にも現れることがあります。同じ画像への繰り返しリクエストでは、以前のキャッシュファイルを再利用できる場合があります。これは、繰り返し行うUI処理が初回リクエストとは異なる経路をたどることがある理由を示す具体例です。
ウォームキャッシュはすべてのメディア読み取りよりもメタデータに効果がある
ライブラリの閲覧では、多数の小さなメタデータやアートワークのオブジェクトにアクセスするため、頻繁に再利用されるデータをメモリの近くに保持すると、インターフェースの応答性が大きく変わることがあります。一方、長時間の映画ストリームでは、一度だけ読み取られ、その後ファイルの後続部分によって置き換えられるデータを読み取る場合があります。
大規模なPlexライブラリでは、アートワークやライブラリ情報が繰り返し参照されるため、クライアント側のメタデータキャッシュがかなり大きくなることがあります。動画ファイル自体をサーバー上に置いたままでも、メタデータキャッシュは増大することがあります。
この違いは、「Plexの動作が速く感じる」という現象を解釈する際に重要です。ウォームなポスターグリッドは、ストレージがより多くの同時ストリームを維持できることの証明にはなりません。また、キャッシュされたファイルセグメントは、映画全体がメモリに収まることの証明にもなりません。ウォームな応答を容量に関する主張へ変える前に、リクエストの種類を明確にしてください。
キャッシュの追い出しによってパフォーマンスが再び変化することがある
ウォームな状態は一時的なものです。アプリケーションがメモリを必要とすると、オペレーティングシステムはキャッシュされたページを回収できます。また、クライアントキャッシュも新しいオブジェクトのために空きを作るため、古いオブジェクトを追い出すことがあります。そのため、1時間前には高速だったリクエストが、ハードウェア障害なしに低速な経路へ戻ることがあります。
ページキャッシュは、利用可能なメモリを使いながら、ほかの処理が領域を必要としたときには明け渡すよう設計されています。メモリ負荷下でのキャッシュ回収について実用的に理解すると、サーバーのワーキングセットや同時実行サービスが変化した際に、同じ繰り返しリクエストの結果が変わる理由を説明できます。
これをテストするには、同じリクエストを、しばらく処理が少ない状態の後に繰り返し、さらにメモリを大量に使用するジョブの実行中にも繰り返します。有効なワーキングセットが追い出されたときだけレイテンシが増大するなら、その結果は突然ディスクが遅くなったのではなく、キャッシュの常駐状態とメモリ負荷を示しています。
ウォームキャッシュの速度と持続可能な容量を分けて考える
容量テストには、少なくとも初回またはよりコールドなアクセス、繰り返し行うウォームなアクセス、そして有効なキャッシュサイズを超える持続的なワークロードを含めるべきです。目的はキャッシュを排除することではなく、各結果をどの層が支えたのか、また再利用による効果がなくなった後もバックエンドのリソースに余裕があるかを理解することです。
実運用のワークロードが同じデータを本当に再利用する場合、ウォームな結果は有効です。しかし、短時間のベンチマークを、はるかに大きなライブラリ、より多くのクライアント、または収まりきらないワーキングセットに一般化すると、誤解を招きます。クライアント、ビットレート、同時実行数と同じように、キャッシュの状態もテスト条件の一部として扱ってください。
特に繰り返し行うNAS読み取りが問題である場合は、SSD読み取りキャッシュとディスクへの直接読み取りを比較してください。Plexに関する確実な教訓はよりシンプルです。ウォームなデータはレイテンシを変えますが、キャッシュがバックエンド経路をカバーできなくなった後にサーバーが維持できる性能を示すには、より大規模で持続的なテストが必要です。
おすすめ商品
テック＆AIハブ
もっと読む
Plexの状態とは何か、どの部分を永続化する必要があるのか？
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。
Plexはローカルセッションとリモートセッションで認証をどのように処理しますか？
Plexの認証はサーバーとアカウントの識別から始まり、その後、ローカルまたはリモートのネットワーク経路によって到達可能性と安全な接続の動作が決まります。
ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか？
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。
