Plexは動作が遅くなる前に同時接続ユーザーを何人まで処理できますか？
Plexユーザー数に役立つ普遍的な上限はありません。安定した同時接続数とは、ストレージ、ネットワーク、またはトランスコードの余裕がなくなる前に処理できる、実際のセッション構成の最大数です。
Direct Playのユーザー10人のほうが、負荷の高いリモートトランスコード2件より軽い場合があります。また、安定した再生中は余裕があるように見えるサーバーでも、複数の視聴者が同時に再生を開始したりシークしたりすると処理が滞ることがあります。実際の再生モード、ビットレート、字幕やHDRの処理経路、リモートアクセス時のアップロード使用量を確認してください。そのうえで、代表的なセッションを1つずつ追加し、CPUモデルやアカウント数から容量を推測するのではなく、再現性のある最初のボトルネックで止めます。
アカウント数ではなく再生経路を数える
Plexにアクセスできる人数と、同時に発生するワークロードの数は同じではありません。まず実際に最も混雑する時間帯を観察し、アクティブな各セッションをDirect Play、Direct Stream、音声のみの変換、動画トランスコードに分類します。これらのモードがサーバーリソースに与える負荷は大きく異なります。
同時セッションが10件以上あっても、Direct Play、リマックス、音声変換、動画トランスコードの各経路がいくつアクティブかによって限界は大きく変わります。単純なユーザー数だけでは、処理が低下し始める地点を予測できません。
テスト構成は、世帯全体や友人全員のリストではなく、現実的に想定される最大同時接続数から作成します。6人のユーザーがほとんど重ならず、全員Direct Playを利用する場合と、4Kトランスコードが3件同時に発生する場合では、必要な容量がまったく異なります。
最初に余裕を失う共有リソースを見つける
同時セッションは、メディアストレージ、サーバーのネットワークインターフェース、音声や字幕の処理に使うCPU、トランスコード用の一時領域、変換に使われるハードウェア映像エンジンを共有します。限界を決めるのは、仕様上の数値が最も高いコンポーネントではなく、実際の構成で必要なリソースのうち最初に不足するものです。
高同時接続のPlexワークロードでは、ドライブ、ネットワーク、トランスコード、内部データ経路にまたがる複数のボトルネックが明らかになることがあります。小規模なホームサーバーでも、同じように複数のリソースを確認してください。
セッションを1つずつ追加しながら、メディアディスクのレイテンシ、ネットワークスループット、CPU、GPUの映像エンジン、メモリ負荷、トランスコード速度を記録します。再生品質が低下する地点と同じタイミングで、最初に一貫して余裕を失う指標が、実用上の容量の境界です。
リモートユーザーではアップロードが別の制限になる
ローカルストリームは高速なLAN内だけで完結できますが、リモートストリームはすべて自宅インターネットのアップロード帯域を共有します。高性能なサーバーでも、元のビットレートまたはトランスコード後のビットレートの合計が、家庭内の他の通信を除いた上り帯域を超えると、ユーザー側では再生が遅くなることがあります。
リモート接続の容量を考える際は、ネットワーク容量とトランスコード容量を別々の上限として扱う必要があります。より高速なGPUでも、過負荷のWANアップリンクから送信できるデータ量を増やすことはできません。
複数のローカルブラウザタブを開くのではなく、自宅の外部からリモート同時接続をテストしてください。アップロードが最初の上限になる場合は、CPUを増設する前に、リモートのビットレートを下げるか接続を改善します。アップロードに余裕があり、トランスコード速度が低下する場合は、計算処理経路のほうが大きな制限です。
再生開始とシークでバースト時の余裕が明らかになる
定常状態での再生は、複数のユーザーが同時に再生を開始したりシークしたりする場合より負荷が低いことがよくあります。こうした瞬間には、ワークロードが落ち着く前に、バースト読み込み、新しいバッファ、メタデータのリクエスト、新たなネットワークフローが発生します。
同時トランスコードの計画では、固定のストリーム数だけでは不十分です。受け入れテストには、同時に開始される可能性のあるファイル形式、目標ビットレート、字幕処理経路、変換処理を含める必要があります。
目標とするセッション構成をすでにアクティブにした状態で、最初のフレームが表示されるまでの時間とシークからの復帰時間を記録します。同時開始時だけ失敗する場合、限界は継続的な計算性能ではなく、バースト時のストレージ性能、アプリ状態のレイテンシ、またはキュー処理にある可能性があります。
バックグラウンドジョブで同じ余裕が減ることがある
スキャン、バックアップ、ダウンロード、分析ジョブは、アクティブな視聴者が必要とするストレージ、CPU、メモリ、ネットワーク容量を消費することがあります。そのため、静かなベンチマークに合格したサーバーでも、実際の家庭内ピーク時には処理に失敗する可能性があります。
目標のセッション構成を、不要なメンテナンスを停止した状態と、代表的なバックグラウンドジョブを1つ実行した状態でそれぞれテストします。その差から、より大きなハードウェアではなくスケジュール調整によって余裕を取り戻せるかどうかが分かります。
バックグラウンド処理を停止しても再生に失敗する場合は、同時接続数の制限を再生経路に設定します。失敗が解消する場合は、競合するジョブのスケジュールを変更するか分離し、低コストなサーバー構成を維持します。
合格したワークロードと失敗したワークロードの定義を、同じ運用手順書に記録しておきます。これにより、クライアント、コーデック、ストレージプール、スケジュールタスクを変更した後でも、運用上の限界を再現できます。
繰り返しテストから運用上の上限を設定する
有用な同時接続数の上限とは、30秒間再生できた最大数ではなく、繰り返し安定して処理できる同時接続構成です。代表的なコンテンツを負荷の高い場面まで再生し、1回シークしたうえで、温度、キュー、トランスコード速度が安定するまで十分な時間システムを監視します。
リモート4Kワークロードテストでは、Direct Play、アップロード、トランスコードの需要を把握して初めてハードウェアの規模を判断できます。これにより、同時接続数の上限をアカウント数ではなく測定した処理量に結び付けられます。
合格した構成と最初に発生した失敗モードを記録します。Direct Playストリームを1つ追加しただけでネットワークが飽和するなら、上限はネットワークによるものです。トランスコードを1つ追加しただけでリアルタイム速度を下回るなら、計算処理が原因です。クライアント、コーデック、ストレージ、ネットワークに大きな変更を加えた後は再テストし、その数値を恒久的なものとして扱わないでください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
