再現可能なホームサーバー負荷でPlexをベンチマークする方法

エヴァ・ウォン

IceWhale author

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

How to Benchmark Plex With a Repeatable Home-Server Workload

有用なPlexベンチマークでは、メディア、クライアント、画質、キャッシュの状態、競合するワークロードを一定に保ちながら、再生を実際に制限している処理段階を測定します。

ホームサーバーは、単発のストリーミングでは高速に見えても、2人目のユーザー、ライブラリのスキャン、コールドキャッシュによってワークロードが変わると処理に失敗することがあります。合成CPUスコアやディスクスコアだけでは、Plexのあらゆる判断を再現できません。Direct Play、トランスコード、字幕の焼き込み、リモート帯域幅では、システムの異なる部分に負荷がかかるためです。小規模なワークロードマトリクスを作成し、条件を変えずに再実行しましょう。

ハードウェアを測定する前にワークロードを定義する

ベンチマークには、重視する再生経路を反映させる必要があります。最低限、既知のDirect Playケースと、サポートする予定の中で最も負荷の大きい変換ケースを用意してください。リモートストリーミングが重要なら、LANの結果がそのまま適用できると仮定せず、実際のアップロード経路か、制御した帯域幅制限を含めます。

リソースごとのボトルネックチェックでは、1つの平均値に頼るのではなく、CPU、メモリ、ネットワーク、ストレージについて、使用率、飽和度、エラーを確認する必要があります。これが、再現可能なPlexベンチマークで確立すべき基準です。

Plexダッシュボードからは、最初に必要な情報を確認できます。再生しているユーザー、使用しているクライアント、ストリームが直接再生かトランスコードかを把握してください。この情報がなければ、CPU使用率やネットワークグラフを見ても、2つの実行結果を比較できるかどうか判断できません。

キャッシュ、クライアント、バックグラウンド処理を制御する

メタデータやファイルシステムキャッシュが温まっていると、繰り返し実行したときに速く見えることがあります。クライアントが違えば再生経路も変わり、スケジュールされたスキャンによってディスクやCPUの負荷が増えることもあります。これらの変数は一定に保つか、意図的に別のテストケースとして含める必要があります。

再現可能なPlexベンチマークを測定する際、明示的なコンテナのリソース制限がなければ、隣接するサービスが同じピーク時間帯にCPU、メモリ、ストレージI/Oを消費し、Plexの動作を変えてしまう可能性があります。

同じリソースが飽和し、同じユーザーに見える症状が繰り返しの実行で現れるとき、そのボトルネックは信頼できます。原因不明の一度きりのスパイクは手がかりであって、容量を示す数値ではありません。

ベンチマークの数値を一般化できなくなる場面

テスト用メディア、字幕、クライアントデバイス、同時実行数が実際の利用状況と一致しなくなると、ベンチマークは家庭での利用を予測できなくなります。また、ソフトウェアアップデートによってトランスコーダー、メディア分析、クライアントの機能が変わった後も、比較可能性は失われます。

再現可能なPlexベンチマークの限界点では、コンテナテストにより、役立つワーキングセットが満たされた後は割り当てるメモリを増やしても、常に性能が向上するとは限らないことが示されています。そのため、メモリは実際に観測した圧迫状況に基づいてサイジングする必要があります。

Plex、クライアント、ドライバー、ネットワークに大きな変更を加えた後は、再テストしてください。再生経路がDirect Playからトランスコードに変わった場合は、以前の結果と直接比較せず、新しいベンチマークシナリオとして扱います。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

小規模なPlexベンチマークマトリクスを使用する

「ローカルDirect Play」「強制トランスコード」「リモート再生」「バックグラウンドサービスとの同時実行」の4つのケースに名前を付けて作成します。再生モード、開始時刻、バッファリング、CPU/GPU使用率、メモリ圧迫、ディスクレイテンシ、ネットワークスループットを記録してください。Plexサーバーのセットアップ基準も、テスト中にクライアントの動作と、サーバー側の演算・ストレージの制限を切り分けるのに役立ちます。

再現可能なPlexベンチマークへの変更を受け入れる前に、テスト済みのIntel N100システムが複数のハードウェアトランスコードを低いCPU負荷で処理しました。これは、広義のCPUカテゴリよりも、コーデックの対応状況やアクセラレーションの方が重要になる場合があることを示しています。

実際にサポートする必要がある、最も負荷の高い再現可能なケースを基準に容量を選びます。必要なケースが十分な余裕を持って成功し、残る遅いケースが実際のワークロードの範囲外であるなら、それ以上ハードウェアを追加する必要はありません。