Windows Virtual Desktop #58 画面転送プロトコルのベンチマーク 

この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。

VDI / DaaS の重要な技術要素の1つとして画面プロトコルがあります。 Citrix であれば ICA や HDX、VMware であればBlast / PCoIP(PCoIP自体はTeradiciですが)、そして Windows Virtual Desktop のRDP?です。?としたのは明確に RDP と説明しているドキュメントが見当たらずだったため。

今回、この記事を書こうと思ったのは、お客様環境でのテレビ会議(音声、動画)の PoC で以下のテスト結果が得られたことがありました。

  • WVD はCPU 使用率は低い。一方、ネットワーク帯域を多く使用する。
  • Horizon Cloud(Blast) はCPU 使用率が高い。一方、ネットワーク帯域の使用は少ない。

この話はプロトコルの違いというよりは、どんなプロトコルでも非圧縮にすればCPU使用率は下がり、ネットワーク帯域を多く消費することは以前からわかっていることでした。 ネットワークの帯域を抑えるということはその分圧縮や最適化に沢山のCPU リソースを使用するためです。

ということで今回は以下の設定に応じてCPUとNW帯域の使用率がどう変わるか、そのベンチマークの実施結果を紹介します。

  1. Host Pool の RDP プロパティ > セッションの動作 > 圧縮
  2. Host Pool の RDP プロパティ > リダイレクト >エンコードされたビデオの品質

1. 検証環境

検証環境は以下の通り。 

仮想の Windows 10 上で Youtube 動画を再生します。 サンプルとしたのは Alibaba Cloud のものですが特にこの内容を選んだ意図はありません。 2分弱と短めだったということがあります。 なお、ディスプレイサイズは 2560×1440 、Youtube はシアターモードなので画面の8割くらいを動画が占める感じです。

また、テスト環境のネットワークについて、クライアントの接続情報は以下の通り。 ラウンドトリップ時間が30ms とイマイチですが帯域幅は 66.78 Mbps です。 

2. 圧縮の有無での違い

2.1. 圧縮を有効 (既定値)

まずは圧縮を有効(既定値)のベンチマークです。

パフォーマンスはタスクマネージャから動画の開始から60秒分を比較していきます。CPU使用率は以下の通りで50%程度を推移しています。 

ネットワークは見えづらいかもですがSend(仮想のWindows 10から物理デバイスへの画面転送通信) を示す点線となります。 最大25Mbps、おおむね5Mbpsが中央値になりそうな見た目です。

2.2. 圧縮を無効 

圧縮設定を無効にします。 予想されるのはCPU使用率が減って、ネットワーク帯域は増える、です。 ホストプールの設定を変更し、一度仮想のWindows 10 からサインアウトし、クライアントでフィードを更新した上で再接続します(サインアウトだけでは反映されない模様)。

CPUは、予想に反して圧縮無しの方がリソースの消費量は多いです。 ”一括”圧縮機能とのことなので単純に圧縮 / 非圧縮ということではないのかもしれません。 参考までにCAD の VDI などでは大量にCPUを消費するので意図的に非圧縮を選択するケースもありました。

ネットワークは圧縮ありよりもリソース使用量は減っています。 一括圧縮無しにするとCPUは増える、ネットワークは減る、という結果となりました。

2.3. 比較

CPUについて、動画の後半部分は一括圧縮無効の方がCPUリソースの消費が多い。

ネットワークの使用帯域について、動画の後半部分は一括圧縮無効の方がスパイクが穏やか。

今回のテストでは、一括圧縮を無効にすることでネットワーク帯域幅を削減できる可能性があることを確認。 可能性としたのは、動画の内容、特性によりその効果についてもっと検証が必要と考えているためです。 また、他のプロトコル同様にネットワーク帯域幅を下げるためにCPUリソースをより多く消費することのトレードオフを考える必要があります。

3. エンコードされたビデオの品質

既定値は”ビデオの圧縮度 – 高。動きが多い場合は品質が低下するおそれがあります” です。

3.1. ビデオの圧縮度 – 高 (既定値)

まずは以下の既定値の環境のベンチマークです。 2.1. の結果と基本は同じとなります。

CPUのリソース(動画開始から60秒分)

ネットワーク帯域(動画開始から60秒分、画面転送通信は”送信”)

3.2. ビデオの圧縮度 – 中

CPUのリソース(動画開始から60秒分)

ネットワーク帯域(動画開始から60秒分、画面転送通信は”送信”)

3.3. ビデオの圧縮度 – 低、画像の品質 – 高

CPUのリソース(動画開始から60秒分)

ネットワーク帯域(動画開始から60秒分、画面転送通信は”送信”)

3.4. 比較

チャートを見る限り、視覚的に顕著な差はありません。 定量的に平均値や統計的に比較する必要はありますが、ビデオの圧縮度の設定はCPUとネットワーク帯域幅の使用量にあまり影響を与えない可能性が高いと思われます。

4. まとめ

結論からいうと、Windows Virtual Desktop の画面転送プロトコルのチューニングパラメータはまだまだ足りないという結果でした。 具体的には Citrix や Horizon のように “帯域の上限指定” と “フレームレートの指定” の2つのチューニングパラメータの実装を期待します。 今回紹介した2つのパラメータよりも、帯域の上限はWAN回線の帯域計算をしやすい、特定ユーザの標準的ではない利用の影響を局所化できるなどメリットがあります。 フレームレートを間引くことは帯域の使用量を減らせるというわかりやすさがあります。 帯域上限は Short path で実装されるとのことなので別途試してみます。

以上