小規模なPlexサーバーでも、アクティブなユーザーが少なければ多数の登録ユーザーをサポートできます。一方、同時に複数のトランスコードが発生すると、すぐにリソースを使い切る可能性があります。
アカウント数は、同時再生と同じリソースを消費するわけではありません。ダイレクト再生、リモート変換、アップロード帯域幅、字幕処理、バックグラウンドスキャンによって、1セッションあたりの負荷は変わります。実際の家庭内の利用状況からピーク時の同時利用シナリオを作成し、測定したリソースのいずれかが飽和に近づくまでユーザーを追加してください。
総アカウント数より同時セッションが重要
同時に2つのダイレクト再生セッションを行う10アカウントのほうが、3アカウントすべてで負荷の高い4K変換が発生する場合よりも処理しやすいことがあります。重要なのはユーザー記録の数ではなく、アクティブな処理量です。
マルチユーザー動画システムでは、同時需要が利用可能なエッジ容量に近づくと、共有帯域幅の競合が発生します。そのため、セッションの重なりを容量モデルに含める必要があります。
1週間にわたって最も混雑する時間帯を記録し、ローカルのダイレクト再生、リモートのダイレクト再生、トランスコードのセッションに分けてください。「ユーザーあたりのストリーム数」を推測して掛け合わせるのではなく、その分布を負荷テストに使用します。
トランスコードによってユーザーあたりの計算負荷が変わる
互換性のないクライアントが1台あるだけで、互換性のあるクライアントなら不要な処理をサーバー側で行うことになります。ハードウェアアクセラレーションによって、小型プロセッサーが同時に処理できる変換数は変わります。
低消費電力のIntel N100は、メディアエンジンが処理内容に対応していれば、複数のハードウェアトランスコードセッションを維持できます。そのため、ユーザー容量はダイレクト再生の場合と変換中心のシナリオの場合で大きく異なります。
家庭内で実際に使われるコーデック、字幕、HDR条件、画質制限を正確にテストしてください。一般的なクライアントの経路がソフトウェア処理にフォールバックする場合、そのハードウェアトランスコードの結果をカウントしてはいけません。
リモートユーザーはアップロード容量を共有する
リモートのダイレクト再生はCPU負荷が低い場合でも、同じ上り回線を奪い合う可能性があります。すでにWAN回線が飽和に近い状態なら、CPUを増強しても解決しません。
リソース飽和の分析手法は、CPUやストレージと同じようにネットワーク経路にも適用できます。単一の高い使用率サンプルよりも、継続的なキューイングやエラーのほうが重要です。
外部ネットワークから複数のリモートセッションを同時に実行し、アップロード帯域の余裕を確認してください。リモートストリーミング経路は、ユーザーが実際に選択する画質設定と同じ条件でテストする必要があります。
バックグラウンド処理によって安全なユーザー数の範囲が狭まる
ライブラリのスキャン、プレビュー生成、バックアップ、関連コンテナは、視聴と同時に実行され、同じCPU、メモリ、ストレージを消費する可能性があります。これらを無視した容量テストでは、安定して利用できるユーザー数を過大評価してしまいます。
大規模なライブラリでは、バックグラウンドのデータベース処理やメタデータ処理が大量のCPUとメモリを消費し、同時再生に利用できる余裕を減らすことがあります。
スケジュールされた処理を有効にした状態でも、ピーク時のユーザーテストを繰り返してください。サポート対象の範囲は、アイドル状態のサーバーで得られた最高記録ではなく、通常想定される最悪の状況でも健全性を保てる最大負荷として定義します。
テック&AIハブ
もっと読む

秘密ブローカーは、プロンプトに認証情報を露出させずにAIエージェントへどのように認証情報を渡すのか?
シークレットレスなホームAIエージェントアーキテクチャを通じて、ワークロードID、ポリシー、トークン発行、リクエストインジェクション、編集、期限切れ、失効を追跡します。

ツールサンドボックスはAIエージェントの副作用をどのように封じ込めるのか?
隔離、機能ゲート、使い捨て状態、送信制御、クォータ、監査ログによって、アクションの安全性を証明することなくAIエージェントの副作用を制限する方法をご覧ください。

制約付きデコーディングはどのようにスキーマ準拠のJSONを生成するのか?
スキーマのコンパイル、トークンマスキング、パーサーの状態、サポートされるサブセット、レイテンシ、切り詰め、そして構造的な有効性が正しい値を保証しない理由を理解する。

