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