ホームサーバーは再生品質が低下する前に、Jellyfinのストリームを同時にいくつ維持できますか？

Jellyfinに一律のストリーム数はありません。持続可能な同時再生数は、通常想定される最も負荷の高いワークロードがクライアントのバッファ余裕を繰り返し消費し切る時点で決まります。

Direct Playのクライアントがほぼ6台あるホームサーバーでも、字幕の焼き付けを伴うリモートHDRストリーム1本より軽い場合があります。最も混雑する通常の時間帯に重なる再生モード、変換処理の段階、競合するサービスを測定しましょう。そうすれば、誤解を招く「CPUあたり何ユーザー」という基準ではなく、実際のワークロードに基づいた現実的な上限を把握できます。

ユーザー数ではなく再生モードを数える

Jellyfinの各セッションは異なる経路に入ります。Direct Playでは主にファイルの読み取りと送信を行いますが、リマックス、音声変換、動画トランスコードが加わるにつれて負荷は段階的に増加します。経路を分類せずにセッション数だけを数えると、メディアパイプラインへの実際の入力が見えなくなります。

有用なワークロード表では、代表的な各クライアントとソースファイルについて、コーデック、HDRの状態、字幕、解像度、リモートビットレートを含むトランスコードの負荷を記録します。

各セッションに名前付きのクラスを割り当てて初めて、数値に意味が生まれます。単純なDirect Playストリーム2本を、画像字幕を伴う4K HDR変換1本と同じ重みで扱うべきではありません。

最も負荷の高い通常経路が最初の上限を決める

同時実行数が増えると、各経路が使用するリソースも増加します。Direct Playストリームはストレージの読み取りとネットワーク配信を追加する一方、トランスコードではデコード、フィルター、トーンマッピング、エンコード、一時ストレージ、CPUフォールバックの処理能力まで消費する可能性があります。

単一のGPUやCPU使用率に頼るのではなく、使用率と飽和状態によってアクティブなリソースを測定します。他のコンポーネントにまだ余裕があっても、1つの段階がリアルタイム処理に間に合わなければキューが形成されることがあります。

繰り返し発生する最初のキュー、またはバッファ余裕の低下が、そのワークロードにおける実用的な上限です。他の場所に未使用の高速なリソースがあっても、その上限は上がりません。

リモートおよび共有ワークロードが境界を動かす

リモートセッションでは通常、ローカルクライアントよりアップロード帯域幅が限られ、遅延も変動しやすくなります。さらに、同時に実行されるバックアップ、インデクサー、ダウンロード処理が同じストレージやネットワーク経路を使用し、視聴者が再生を開始したりシークしたりするまさにその時間帯に余裕を削ることもあります。

メディアとクライアントのポリシーを一定に保ちながら、複数アプリのリソースモデルを使ってローカルとリモートのケースを比較します。リモートの場合だけバッファ余裕が失われるなら、その境界はメディアエンジンではなく、経路またはアップロード帯域幅にあります。

したがって同じサーバーにも、ローカルDirect Play、ローカルトランスコード、リモート配信、同居サービスを含むピークワークロードという複数の上限があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

再現可能な容量のしきい値を設定する

有用な受け入れテストでは、まず想定される最も負荷の高いセッションを開始し、通常の同時ストリームを1本ずつ追加します。起動時間、継続中のバッファ状態、ドロップフレーム数、キューの深さ、最初に飽和へ達したリソースを記録します。

停止基準にはコールドおよびウォームベンチマークを使用します。ダッシュボードに高い使用率が表示された時点ではなく、遅延、エラー、キューイングが繰り返し発生する時点で、十分なヘッドルームを確保します。

目標とする組み合わせが複数回にわたって安定した再生と目に見える余裕を維持できるまでテストし、そこで停止します。その結果を、異なるメディアやクライアントに適用できる一律のストリーム数へ変換しないでください。