Plexの遅延がクライアント側とサーバー側のどちらに起因するかを見分ける方法

同じサーバーパスが他の環境で正常に動作する場合、Plexの遅延はクライアント側に起因し、複数のクライアントで同じボトルネックが再現する場合はサーバー側に起因します。

難しいケースはその中間にあるため、直感ではなく置き換えテストを行ってください。メディアファイルとネットワークを固定し、クライアントだけを交換してから、別のファイルや再生モードでも繰り返します。同時にサーバーのリソース使用率とログを確認し、レンダリング、デコード、ネットワーク配信、サーバー処理を切り分けられるようにします。

同じメディアで遅延を再現する

ファイルとクライアントを同時に変更すると、比較ができなくなります。既知のテストファイルを1つ用意すれば、特定のデバイスだけが遅いのかを確認するための安定した負荷を作れます。

クライアント固有のPlex回帰によって、一部のプラットフォームだけに問題が発生し、他のプラットフォームは正常に動作することがあります。

同じネットワーク上の2台のクライアントで、同じアイテムを同じ品質で再生し、起動時間とエラーを比較します。遅延が1台のクライアントでのみ再現する場合は、サーバーを変更する前に、クライアントのコーデック、アプリのバージョン、デバイスのデコード処理を確認します。

サーバーが飽和しているか確認する

サーバー側の遅延が発生すると、遅いリクエストの処理中にCPU、メモリ、ディスク、ネットワーク、またはワーカーの動作にその兆候が現れるはずです。ホストの使用率が十分に低いままなら、クライアントまたはネットワーク経路の可能性が高くなります。

使用率、飽和度、エラーの確認により、単にビジーなリソースと、実際に制約を受けている、または障害が発生しているリソースを切り分けられます。

高速なクライアントセッションと低速なクライアントセッションで、同じホストのメトリクスを取得します。遅いクライアントでサーバーに対応する負荷が発生しない場合は、サーバーのリソースを増やす前に、エンドポイントまたは通信経路を調査してください。

Direct Playとトランスコードを別々にテストする

クライアントがDirect Playでは高速でも、互換性の問題によってサーバーが別の再生経路に切り替わると遅くなることがあります。両方のモードをテストすれば、遅延がクライアント自体に伴うものか、それともクライアントが引き起こすトランスコード負荷に伴うものかを確認できます。

Plexのトランスコードが必要になると、クライアントの互換性によってデコードとエンコードの処理がサーバー側に移されます。

まず、両方のクライアントでDirect Playできることが分かっているメディアファイルを使用し、その後、問題のある形式や字幕の条件を追加します。変換の開始時だけ遅延が発生する場合は、クライアントのインターフェースではなく、トランスコーダーと一時ストレージを確認します。WAN経由でのみ遅延する場合は、既知のリモートPlexストリーミング経路でも同じ組み合わせを再テストし、ローカルとリモートの挙動が混同されないようにします。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

単発テストではなく経路マトリクスを使う

最も効率的な診断方法は、同じネットワーク条件で、クライアントAとBをDirect Playとトランスコード再生の両方で比較することです。このマトリクスを使えば、無関係な設定変更を積み重ねるのではなく、どの変数が障害と連動しているかを確認できます。

リモートでの4K Plexストリーミングには持続可能なアップロード帯域が必要で、サーバー側の変換が発生する場合もあります。

クライアントA／Direct Play、クライアントA／変換、クライアントB／Direct Play、クライアントB／変換の4つの結果を記録します。1つの組み合わせで一貫して失敗する場合は、まずその層を修正し、次の仮説に進む前にマトリクスを再実行します。