キャッシュを容量と取り違えずにJellyfinのパフォーマンスを測定する方法
Jellyfinのベンチマークでは、ウォーム状態のファイルシステムやメタデータキャッシュを、コールドスタート時のハードウェア性能の証拠とみなすと、誤解を招く結果になります。
2回目のライブラリを開く操作や繰り返しのストリーム再生では、すでにメモリにあるデータを再利用できます。一方、初回実行ではストレージ、メタデータ、プロセスのセットアップを待つことがあります。どちらの状態も有用ですが、答えている問いは異なります。キャッシュの再利用をハードウェア性能の向上と取り違えないよう、同じメディア、クライアント、品質、競合ワークロードで、コールドテストとウォームテストを別々に実行してください。
コールド実行とウォーム実行は異なる問いに答える
コールドテストでは、ストレージから状態を取得してワーキングセットを再構築するコストが明らかになります。一方、ウォームテストでは、有用なデータが常駐した後の繰り返し動作を確認できます。両者を平均すると、その仕組みが見えなくなります。
データがLinuxのページキャッシュに残っている間は、繰り返しの読み取りでストレージ処理を回避できる場合があります。
再起動後の初回実行を、2回の繰り返し実行とは分けて記録してください。ウォーム時の結果のほうが良く見えるからといって、コールド時の結果を破棄しないでください。
メタデータのベンチマークは特にキャッシュの影響を受けやすい
ポスターグリッド、検索、ライブラリページでは、同じ小さなファイルやデータベースページに繰り返しアクセスすることがあります。これらのワークロードでは、長時間のメディアのシーケンシャルストリームよりも、ウォームキャッシュによる効果が大きく現れることがよくあります。
Jellyfinのコンテナデータを低速なメディアディスクから移動すると、コールド時の処理経路が直接変わります。あるNAS構成では、メディアをスリープ中のHDDストレージに残したまま、JellyfinのアプリデータをSSDに保存しています。
再起動後に名前を指定したライブラリを開いて検索するまでの時間を測定し、その後もう一度繰り返してください。差が大きい場合は、ストレージ比較に両方の数値を含めてください。
バックグラウンドジョブは比較を汚染する可能性がある
スケジュールされたスキャン、サムネイル処理、バックアップ、または別のコンテナが、実行間に有用なページを追い出したり、ストレージキューを消費したりすることがあります。「キャッシュの結果」は、競合するワークロードが把握されている場合にのみ解釈できます。
Jellyfinでは、スケジュールされたメディアスキャンを通じてライブラリ処理を実行するため、ベンチマーク実行ごとに変化させず、バックグラウンドのメンテナンスを一定に保つ必要があります。
負荷の高いタスクを停止した状態で、制御されたベンチマークを1回実行し、その後、通常のサービスを稼働させた状態でもう1回実行してください。家庭用メディアサーバーのワークロードマップは、実際の受け入れテストに含めるべき重複処理を判断するのに役立ちます。
性能容量とは、通常条件における再現可能な最悪ケース
ハードウェア容量は、最速のキャッシュ結果や、誰も経験しない人為的な最悪ケースではなく、想定される条件下でサーバーが継続して処理できるワークロードを示すべきです。テストには、名前を付けたシナリオと合格基準が必要です。
USEメソッドでは、1つの経過時間の数値ではなく、リソースの飽和状態とエラーに基づいて容量を評価します。
起動、検索、再生それぞれの合格条件を定義し、変更を加えるたびにコールドとウォームのケースを繰り返してください。該当するケースで一貫した改善が確認できた場合にのみ、システムが改善されたと判断します。
おすすめ商品
テック＆AIハブ
もっと読む
秘密ブローカーは、プロンプトに認証情報を露出させずにAIエージェントへどのように認証情報を渡すのか？
シークレットレスなホームAIエージェントアーキテクチャを通じて、ワークロードID、ポリシー、トークン発行、リクエストインジェクション、編集、期限切れ、失効を追跡します。
ツールサンドボックスはAIエージェントの副作用をどのように封じ込めるのか？
隔離、機能ゲート、使い捨て状態、送信制御、クォータ、監査ログによって、アクションの安全性を証明することなくAIエージェントの副作用を制限する方法をご覧ください。
制約付きデコーディングはどのようにスキーマ準拠のJSONを生成するのか？
スキーマのコンパイル、トークンマスキング、パーサーの状態、サポートされるサブセット、レイテンシ、切り詰め、そして構造的な有効性が正しい値を保証しない理由を理解する。
