Plexは異なるクライアントが同時接続している状況でも、スムーズなダイレクトプレイを維持できますか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

すべてのセッションが互換性を保ち、共有ストレージとネットワーク経路に十分な余裕がある場合、Plexは異なるクライアントが同時に接続していてもスムーズなダイレクト再生を維持できます。

異なるクライアントが同じコーデックやビットレートを使う必要はなく、互換性のないエンドポイントが1台あっても、ほかのクライアントが自動的に影響を受けるわけではありません。制限が現れるのは、メディアの読み取り、ネットワークトラフィック、クライアントのバッファー、または新たに発生したトランスコードが共有リソースを奪い合うときです。したがって、実現可能性は対応視聴者数の固定値ではなく、混在ワークロードのテストによって確認する必要があります。

ダイレクト再生はセッションごとに決まる

Plexは、要求されたファイルを各クライアント、選択されたトラック、画質設定、配信経路に照らして評価します。同じタイトルを要求した2人のユーザーでも、一方のクライアントはソースをそのまま受け付け、もう一方はリマックスやトランスコードを必要とするなど、異なる経路を取ることがあります。同時接続によって、これらの互換性の判断がサーバー全体で1つのモードに統合されることはありません。

Plexはクライアントと配信条件に基づいて各リクエストを評価するため、同じサーバー負荷の下でもダイレクト再生とトランスコードのコストは異なります。まず各セッションを独立したクライアント側のエッジとして扱い、そのうえでセッションが共有するストレージ、ネットワーク、計算リソースを評価してください。

そのため、トランコードしているクライアントが1台あるからといって、全員のダイレクト再生が失敗しているとは限りません。セッションごとにダッシュボードを確認し、合計リソース使用量を解釈する前に、映像、音声、字幕、ビットレート、経路を分類してください。

メディアの合計読み取り量がストレージの最低要件を決める

ダイレクト再生の各セッションでも、ソースファイルの読み取りは発生します。クライアントが混在するとビットレートは大きく異なる可能性があり、ユーザーが異なるタイミングで再生開始やシークを行うことで、単一のテストを繰り返す場合よりもストレージ負荷が突発的になることがあります。ストレージに必要な最低性能は、実際の読み取りパターンの合計に、同じプール上で行われるほかの処理を加えたものです。

ストレージとネットワークがクライアントの要求を上回っていれば、対応可能なNASは複数のメディアストリームを同時に処理できます。これは手法の一例であり、別の筐体、ディスク構成、ライブラリにそのまま適用できるストリーム数の保証ではありません。

同一の低ビットレートサンプルではなく、実際の利用状況を代表するファイルを使ってください。別のセッションを開始したときにダイレクト再生が停止し始め、ディスク遅延や使用率が急上昇するなら、ストレージ競合が共有ボトルネックである可能性があります。

GPUがアイドル状態でも、ネットワークは合計負荷を運ぶ

ダイレクト再生では映像のエンコードを回避できますが、サーバーのインターフェース、スイッチのアップリンク、アクセスポイント、WANのアップロード帯域、クライアントのリンクは、依然としてすべてのストリームを運びます。そのため、CPUやGPUのグラフがほぼ空でも、混在ワークロードによって共有ネットワークの一部が飽和することがあります。

実際のPlex環境では、同じ混雑時間帯にダイレクト再生とトランスコードのセッションが混在することがあります。コミュニティで報告された台数は特定シナリオの証拠にすぎません。ほかの環境にも適用できる原則は、実際の同時負荷の下で、最も遅い共有リンクと最も重い変換を測定することです。

代表的なピークビットレートを合計し、再生中にリンクの実際の速度を確認してください。合計値がサーバーのリンク速度を大きく下回っているのにテレビ1台だけがバッファリングする場合、制限要因はサーバーの同時処理能力ではなく、クライアント側の経路である可能性があります。

1つのトランスコードで共有リソースの構成が変わる

クライアントが混在する環境には、希望するソースを受け付けられないエンドポイントが少なくとも1台含まれることがよくあります。そのセッションが加わると、従来はソースの読み取りだけだったワークロードに、デコード、エンコード、一時ストレージ、さらに異なるネットワークビットレートが追加されます。その結果、CPU、メモリ、ストレージ、または同じアップリンクを介して、ダイレクト再生のセッションと間接的に競合することがあります。

Plexホストは複数の同時ストリームに対応できるよう構成できますが、各セッションは限られたストレージ、メモリ、ネットワーク、計算リソースを共有します。実際に重要なのは、必要なトランスコードを余裕を持って処理しながら、ダイレクト再生のセッションにも配信上の余裕が残るかどうかです。

互換性のないクライアントを外した状態で同じダイレクト再生セットを再実行し、その後で戻してください。ほかのセッションがトランスコードの開始後にのみ劣化するなら、Plexに全体的な混在クライアントの不具合があると決めつけず、どの共有指標が変化したのかを切り分けてください。

実際の同時処理限界は、混在ワークロードのテストで決まる

最適な受け入れテストでは、家庭内で実際に使うクライアントの種類を同時に起動します。たとえば、高ビットレートのローカルテレビ、リモート接続のスマートフォン、ブラウザー、そしてトランスコードが発生すると分かっているエンドポイントです。再生開始、シーク、安定再生の間、セッションごとの再生モードに加えて、ストレージ、ネットワーク、CPU、GPU、バッファーの兆候を記録してください。

十分に構成されたNASは、同じシステム上で複数のメディアクライアントとトランスコードを処理できます。製品固有の結果そのものが重要なのではありません。ほかの環境にも応用できる方法は、混在するクライアント、バックグラウンド処理、ストレージを組み合わせ、競合が現れるまで十分な時間テストすることです。

すべてのセッションがダイレクト再生であることを確認できたら、次の限界はネットワークの同時処理限界です。Plexは、互換性のあるクライアントまたは共有リソースのいずれかが、測定された余裕を失うまで、混在クライアントによるスムーズなダイレクト再生を維持できます。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.