Windows Media Server のチューニング

Eduardo Oliveira and Gail McClellan
Microsoft Digital Media Division

December 2001
日本語版最終更新日 2002 年 1 月 22 日

概要

この文書は、Microsoft Windows Media Services version 4.1 が実行されているサーバーで実施されたパフォーマンス評価テストの結果を提供しています。このデータは、Windows Media server がリソースをどのように使うかをより深く理解する手助けとなり、これによってあなたの環境のためのベストなキャパシティプランを立てることができるでしょう。

目次

はじめに
ボトルネック

• ディスクスループット
• 帯域幅
• CPU
• メモリ

• プロトコル
• ビットレート
• ブロードキャスト公開ポイント vs オンデマンドストリーム
• プロセッサの数
• シングルビットレート vs. マルチビットレート
• FastSendDatagramThreshold キー

はじめに

この文書は、Microsoft® Windows Media™ Services version 4.1 が実行されているサーバーで実施されたパフォーマンステストの結果を含んでいます。テストはすべてコントロールされた実験環境で実施されました。評価サーバーの反応として提示されたデータは貴重なものではありますが、実世界のシナリオを単純化したものに沿って収集されたものにすぎません。このデータを絶対的な数字として使用したり、制作環境に適用したりするべきではありません。その代わり、その結論を、より良いチューニングのため、そして あなた独自の状況によって可能な限り最高の結果を生み出すようサーバーを最適化するために利用してください。この文書は次のトピックを含んでいます。

• ボトルネック: Windows Media server のパフォーマンスに影響を与え得る主要な問題について説明しています。
• パフォーマンス: 評価サーバーパフォーマンスを評価するための基本的な情報を提供します。
• 付録: キャパシティプランニングのための典型的なプロファイル、ユニキャストと Transmission Control Protocol (TCP) キーの説明、パフォーマンステストから集められたすべてのデータのリストを提供します。

ボトルネック

Windows Media Service のパフォーマンスに影響を与えるボトルネックのメインは、ディスクスループット、使用可能帯域幅、CPU、メモリです。CPU とメモリの問題は、ディスクや帯域幅の問題より容易に見分けがつきます。多くのケースでは、ディスクスループットの不足は、主としてオンデマンドストリーミング(特にLAN環境で)のためのシステムアロケーション上のエラーの主要な原因となります。そして帯域幅の不足は、インターネットパフォーマンスと結び付けられる主要な問題です。

ディスクスループット

この章では、ディスクスループットと結びつく問題と、どうやってベストパフォーマンスを生み出すかについて論じます。２つの問題がディスクパフォーマンスと関係してきます。

1. ディスクは、多くの低ビットレートストリームを供給しているより、少しの高ビットレートストリームを供給しているほうがより良いスループットを維持しています。なぜなら、物理ディスク上のデータをシークする時間がまったくかからないからです。
2. Windows Media server は NTFS ファイルキャッシュ メカニズムを使いません。

最初の問題と関連して、ディスクがおおよそ 650 の 22 KB ストリーム(~14 megabits per second (Mbps))と 45 の 700 KB ストリーム (~31 Mbps) を供給できることをテストで示します。同じディスクから供給するクライアントをもっと増やした時の遅延読み込み完了数の結果は、 Windows Media Unicast service のカウンター Late Reads を見て判断することができます。

ディスクパフォーマンスと関連する２つ目の問題はとても重要です。なぜなら、クライアントがそれをストリームするごとに、それぞれのファイルが１回ずつ読み込まれることを伝えているからです。大きなコンテンツファイルをキャッシュすると、いくつかの状況ではディスクのページングを引き起こす可能性があるので、 Windows Media Service は NTFS キャッシュ メカニズムを使わないのです。ディスク ページングはサーバーパフォーマンスにとって有害であり、避けるべきことです。もしキャッシングが要求されたり、個別のシステムのパフォーマンスに有益であったりする場合は、ディスクコントローラ の キャッシング メカニズムを 使用するべきです。 SCSI と Fiber Channel ベンダーの両方が、発生し得るシナリオのために有益となるコントローラ キャッシュ オプションを提供しています。

パフォーマンステストでは、ディスクが区分けしたボリュームとして使われていて、公開ポイントがそれぞれに作られている時に、ベストなサーバーパフォーマンスが得られました。

注: RAID セットアップにより課せられるオーバーヘッドは、ディスクコントローラのキャッシュ (53 メガバイト (MB)) により補われて良い結果をもたらしているので、テストマシンでの RAID 0 や RAID 5 アレイの使用は問題とはならなかったでしょう。

マルチビットレート (MBR) コンテンツを使っている時重要なのは、 ディスクから読み出されるデータの量は、現在ユーザーに配信されているストリームだけでなく、すべてのエンコードされた帯域幅の総量であることを思い出すことです。結果は、MBR がディスクにかなり負担をかけるということでした。

ディスクスループットを最適化するための追加提案は、区分けしたディスクにオペレーティングシステムを配置してあなたのディスクでパフォーマンステストを実施することです。ディスクパフォーマンスのいろいろな問題を観察するには、Late Reads カウンターを使ってください。

帯域幅

帯域幅の不足が原因の失敗は、一般に Windows Media Unicast service の Stream Errors カウンターを見て診断できます。(このカウンターが bytes で表示されることに注意してください) 接続クライアントの数の増大が、ビットレートによるのか、Allocated Bandwidth カウンターの結果によるのか、によって、集合した帯域幅の総数を見出せます。個々の network interface card (NIC) が提供できるスループットの総量を明らかにすることは、より難しいタスクとなります。

以前のテストで、Windows Media 環境で多くの 100 Mbps Ethernet card が おおよそ 60-70 Mbps の出力データを維持することが観察されました。gigabit NIC の結果では、もっとより広い傾向があります。 gigabit Ethernet card で限定されたテストでは、300 Mbps から 400 に及ぶ結果を生じました。いくつかのケースでは、カードがより多くのデータを送ることが、PCI ローカルバススピードによって阻害されました。

ベストのパフォーマンス結果を得るためには、NIC は全二重モードにセットします。

CPU

CPU 消費量のモニターは、簡単でかつ共通のタスクです。個々のパフォーマンスのための推奨 CPU の範囲について知ると、より複雑になります。もしサーバー CPU load が100パーセントに到達していないと、パフォーマンスは良いように見えます。しかしながら、いくつかの操作はより CPU 集中型で、新しいクライアントが接続してこなくてさえ、 CPU 使用率は相当なものになります。 CPU 使用率は、ストリーミング中の素早い早送り・シーク・一時停止などの、ユーザーが実行する操作に大きく依存します。

CPU にもっとも依存する操作は、新しいクライアントの接続です。なぜなら、一秒間ごとに接続できる数は限られているからです。この値を増やすと、特に多くの数の新しいクライアントが同時に接続しようとした場合に、システムにすでに接続しているクライアントへの問題を引き起こします。

注: MaxConnectionsPerSecond キーの詳細は、付録 B を参照してください。 サーバーが 30パーセントから 50パーセント以上は CPU を使用しないこと、そしてストリーミング継続中は決して 60パーセントのレベルを越えないことを推奨します。このことで、新しいクライアント接続の際に、十分な CPU パワーが確実に使用可能になります。

次の章ではシステム上の CPU の数、接続クライアント数、コンテンツのビットレート、オンデマンド vs ライブ、などなどに関係して、Windows Media serverがどのように挙動するのかを論じます。

メモリ

CPU 使用率と同様に、メモリの利用可能状況をたどることは比較的簡単です。 Windows Media server はファイルキャッシングにメモリを使いません。だから必要なメモリはきわめて少ないのです。必須メモリは、接続クライアント数、ファイルのビットレート、送信がライブかオンデマンドか、に直接関係します。

多少の RAM が使用可能になっていることも重要です。メモリ消費量の概算は次の章で提供されます。アロケートされたメモリはコンピュータ構成に依存して変化しないので、１つのシステムから他システムに、充分採り入れることができる少数のパラメータ値のひとつとなります。

パフォーマンス評価

この章では次の要因をベースとするパフォーマンス評価を提供します: プロトコル、ビットレート、ブロードキャスト公開ポイント vs オンデマンドストリーム、プロセッサの数、シングルビットレート vs マルチビットレート、FastSendDatagramThreshold キー。

プロトコル

次のダイアグラムは、オンデマンドコンテンツをストリームしている時に、CPU消費量は線形に増大するわけではないことを示しています。パフォーマンステストによれば、4,000 MMSU クライアントの CPU 使用率は 27パーセントでした。追加で 500 クライアントが接続すると、CPU load は 60 パーセントに増大します。次のダイアグラムは、MMSU, MMST, HTTP プロトコルの CPU 使用率を表示しています。

MMSU プロトコルを使用すると、同じ CPU load レベルの MMST や HTTP に比べて 53 パーセント以上のクライアントにストリームすることが可能になります。(4,000 vs 2,700 クライアント)

図 1. Processor time % (オンデマンドの 22 Kbps ファイル)

次のダイアグラムは、テストの結果を表示しています。

図 2. ワーキングセット (オンデマンドの 22 Kbps ファイル)

22 Kbps テストファイルでは、それぞれの MMSU クライアントがおおよそ 103 KB, HTTP が 63.5 KB, MMST が 62.9 KB のメモリを使用していました。 MMSU プロトコルはよりCPUを使いませんが、よりメモリを要求します。(MMSTより 60パーセント増)

ビットレート

１台の Windows Media server がサポートできるクライアント数の見積りを算出する時、ビットレートが異なることに関連するサーバーの測定方法のアイデアを持っていなければなりません。このサーバーは 22 Kbps と 220 Kbpsファイルのストリーミングでテストされました。 22 Kbpsファイルを使う時には500 クライアントが接続され、220 Kbpsファイルを使う時には50 クライアントが接続されました。トータルのスループットは同等でしたが、クライアント数とファイルのビットレートは異なっています。

次のダイアグラムは、50 の 220 Kbps ストリームよりも 500 の 22 Kbps ストリームの方がより多いCPU を消費したということを示しています。その結果、CPU 使用率はビットレートと線形に増大してはいません; ばらばらに増えています。

図 3. Processor time % (MMSU from BBP)

直接の結果として、１枚の gigabit NIC は 22 Kbpsファイルのストリームでいっぱいにはなりません。なぜなら、多くのシステムがプロセッサのパワーの外側で実行し得るからです。 700 Kbps または 1 Mbps ファイルをストリームする時、CPU が限界の要因にはならないだろう、と考えるのがより適当でしょう。高ビットレート コンテンツのテストの中で、CPU は NIC や ディスクスピードより問題となりにくいことが立証されました。

図 4. ワーキングセット (MMSU from BBP)

同じことがメモリにも適用できます 22 Kbps ストリームのケースで、RAM は出力の Kbps ごとに 730 bytes の割合でアロケートされましたが、 220 Kbps ストリームでは、使用はたった 90 bytes に減少しました。

CPU もメモリも両方で、サーバーパフォーマンスは、ストリームのビットレートが高くなるのに比例して良くなりました。

ブロードキャスト公開ポイント vs オンデマンドストリーム

ブロードキャスト公開ポイント (BPP) からのストリーミングデータは、オンデマンドストリーミングよりもよりリソースを消費しません。 BPP はライブフィードとステーションから供給できます。２つの送信タイプの間の一番大きな違いは、 BPP 送信はほぼ線形に測定され、オンデマンドはほぼ指数曲線風に測定されます。次のダイアグラムは、ライブとオンデマンドストリームの両方でのプロセッサタイムを表示しています。

図 5. Processor time % (MMSU 22 Kbps ファイル)

35 パーセント CPU 以下では、オンデマンドストリームは BPP よりプロセッサタイムを使いません。 とは言っても、BPP はシステムアドミニストレータに、システムがどれくらい多くのクライアントをより簡単にサポートできるのかを予想するだけでなく、より多くの数のクライアント接続を可能にします。１台のWindows Media server に接続する 22 Kbpsのクライアントの最高数は、この文書が公開された当時で 9,500 でした。そのクライアントは複数の BPP からストリーミングしていました。

図 6. ワーキングセット (MMSU 22 Kbps ファイル)

BPPストリームに使用されるメモリはまた、比較的少量です。それぞれの 22 Kbps MMSU クライアントのそれぞれで、サーバーは 16.3 KB のメモリを使用していました。オンデマンドストリームでは、サーバーはおおよそ 103 KB のメモリを使用しています。サーバーは、22 Kbps ファイルを 4000 のオンデマンド ユニキャスト クライアントにストリームするために、おおよそ 512 MB の導入済 RAM を要求します。ライブストリームでは、同じ数のクライアントにストリームするためのメモリ要求は 128 MB の導入済 RAMです。

プロセッサの数

Windows Media server は、ストリームが特にライブなのかオンデマンドかに依存して、プロセッサ追加時の測定がとても難しくなります。

図 7. Processor time % (MMSU 22 Kbps ファイルオンデマンド)

オンデマンドストリームでは、プロセッサ数とシステムが供給できるクライアント数は、同じ比率では増加しません。シングルプロセッサでは、2,000 クライアントまで接続でき、CPU 使用率を 最大 30 パーセントで維持できます。２プロセッサでは、2,600 クライアント (プロセッサごとに平均 1,300)接続できます。４プロセッサでは、4,200 クライアント (プロセッサごとに平均 1,050)接続できます。

一方コンテンツがライブの場合、サーバーはかなり充分に測定できます。 これは次のダイアグラムで表示されます。

図 8. ワーキングセット (MMSU 22 Kbps ファイル ライブ)

CPUを30 パーセントあたりで維持するという原則に従って、シングルプロセッサでおおよそ1000 クライアントを接続できます。２プロセッサでは、おおよそ 2000 クライアント、４プロセッサではおおよそ 4000 クライアントです。

シングルビットレート vs. マルチビットレート

マルチビットレート (MBR) の問題で、すべて異なるビットレートのファイルは、クライアントが受け取るかどうかは別として、とにかくディスクから読み込まれる必要があります Late reads は早めに上昇し始めます。なぜならディスクから読まれるデータの大半が大きいからです。 この問題が無ければ、MBR ファイルはシングルビットレート (SBR) ファイルと同様な動きをするでしょう。 オンデマンドストリームでは、CPUはそうでないのに対してメモリ使用は線形に増加しました。

FastSendDatagramThreshold キー

パフォーマンステストは次のことを示しています。 FastSendDatagramThreshold キーにより適当な値を使うと、サーバーパフォーマンスでとても良い効果があがります。 この threshold キーは、データグラムが速い I/O パスを通るべきか、送信時にバッファされるべきかを決めるために Microsoft Windows® 2000 で使われます。速い I/O とは、メモリをマッピングしたり I/O サブシステムを通ったりする代わりに、データをコピーしてI/O サブシステムをバイパスすることを意味します。

FastSendDatagramThreshold キーのデフォルト値は 1,024 です。もしストリームがこの値を超えてパケットに送られる場合は、追加操作が必要となります。結果として、context switch の総数と CPU 使用が増え、サーバーが供給できる最大クライアント数が減少します。次のダイアグラムは、threshold キーをより望ましい値(このケースでは1,500 bytes)に変えたシステムと変えないシステムを表示しています。

図 9. Processor time % (MMSU 100 Kbps ファイル オンデマンド)

threshold キーを変えることで、高いビットレートのファイルだけが 有利になっているのは、これらのファイルだけがデフォルトの限界を超えてパケットに送られているからです。たいてい、.asf 拡張子をもったWindows media ファイルが 1,024 以上のパケットに分割され始めるビットレートは、 100 Kbps です。望ましい threshold の限界を決めるには、Windows Media ファイルのパケットサイズを特定しなければなりません。それから、キーをより高い数にセットします。

注: いくつかの典型的なサンプル値は次のようなものです: 100 Kbps ストリームには、キーを 4,096 にセット、500 Kbps ストリームにはキーを 9,600 にセット、そして 1 Mbps ファイルには、キーを 16,000 にセット。

キーを変えることなしに、CPU を 30 パーセント以下に維持しつつサーバーに接続が可能なのは 750 クライアントです。キーを変更することで、CPU を 40 パーセントまで使用して 1,050 クライアントが接続することができました。

図 10. Pool non-paged bytes (MMSU 100 Kbps ファイル オンデマンド)

threshold キーを変更するもう一方の影響として、サーバーのためにアロケートされる non-paged pool bytes 数の増大があります。しかしながら、前のダイアグラムが示しているように、この増加は何か問題を起こすほどには大きくありません。次のダイアグラムは、パケットサイズが threshold を超えた時の context switch の増加を図解しています。

図 11. Context switches/sec (MMSU 100 Kbps ファイル オンデマンド)

付録 A: プロファイル

テストは22 Kbps から 1 Mbps の範囲のプロファイルで実施されました。

22 Kbps

図 12. Processor time % (MMSU 22 Kbps ファイル)

図 13. ワーキングセット (MMSU 22 Kbps ファイル)

表 1. 22 Kbps でのオンデマンドとライブプロファイルの比較

100 Kbps

図 14. Processor time % (MMSU 100 Kbps ファイル)

図 15. ワーキングセット (MMSU 100 Kbps ファイル)

表 2. 100 Kbps でのオンデマンドとライブの比較

200 Kbps

図 16. Processor time % (MMSU 200 Kbps ファイル)

図 17. ワーキングセット (MMSU 200 Kbps ファイル)

表 3. 200 Kbpsでのオンデマンドとライブの比較

500 Kbps

図 18. Processor time % (MMSU 500 Kbps ファイル)

図 19. ワーキングセット (MMSU 500 Kbps ファイル)

表 4. 500 Kbps でのオンデマンドとライブの比較

700 Kbps

図 20. Processor time % (MMSU 700 Kbps ファイル)

図 21. ワーキングセット (MMSU 700 Kbps ファイル)

表 5. 700 Kbps でのオンデマンドとライブの比較

1Mbps

図 22. Processor time % (MMSU 1 Mbps ファイル)

図 23. ワーキングセット (MMSU 1 Mbps ファイル)

表 6. 1 Mbps でのオンデマンドとライブの比較

付録 B: キー

この章ではユニキャストと TCP のキーの情報を提供します。

ユニキャスト キー

MaxConnectionsPerSecond

Location: HKLM\System\CurrentControlSet\Services\Nsunicast\Parameters\MaxConnectionsPerSecond

Type: DWORD

Default: 25
接続要求がクライアントから Windows Media server に送られた時、同時に接続しようとするクライアント数が 25に到達するか、または自分で値をセットしない限り、要求は即時(１秒以内)に実行されます。次々発生する接続要求はすべて、サーバーに受け取られ、キューに置かれます。 コンピュータがそれぞれまったく同じリソースを持っていたとしても、すべてのサーバーに適当なクライアント接続レート値、というものはありません。クライアント接続レートは、要求が実行されているときの使用可能リソースに依存して、既に接続されているクライアントのためのストリームクオリティに影響を与えます。複数の CPU と大きなメモリを持ったサーバーは、より多くのクライアントをサポートします。が、もしシステムリソースが高い割合で使用される時、接続レートの増加は接続クライアントのストリームクオリティを減少させます。ローエンドサーバーは、サーバー load が低いため、50 接続／秒を扱うことができます。接続レートの値を決める時には、要求が実行されている時のリソース使用を検討しなければなりません。ストリームクオリティへ影響を与えずにサーバーが処理できる、サーバー要求クライアント数は、そのサーバーから現在コンテンツを受け取っているクライアント数に依存して変化します。 この文書で提供されているテストでは、MaxConnectionsPerSecond キーは 100 にセットされましたが、クライアントはいつももっと低いレートで接続されていました。 CPU 使用が高いとき、クライアント接続レートはそれにしたがって調整されます。

TCP キー

MaxUserPort

Location:
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\MaxUserPort

Type: DWORD

Default: 5,000 このパラメータは、アプリケーションがシステムへ使用可能ユーザーポートを要求したときに使われる最大ポート数をコントロールします。デフォルトでは、ポートの範囲は 1,024 から 5,000 が使用可能です。接続しようとするクライアントが多すぎるときと、この値が変更されたとき、サーバーはポートを超過することができます。限界は、通常は 3,700 MMSU クライアントより少しだけ上でヒットします。 HTTP や MMST のケースでは、クライアント数の限界はより高くなります。もし同時に接続するクライアント数を多くしたいなら、この値を 0xFFFE にセットすることを推奨します。

FastSendDatagramThreshold

Location:
HKLM\System\CurrentControlSet\Services\AFD\Parameters\FastSendDatagramThreshold

Type: DWORD

Default: 1,024

デフォルトより小さめのデータグラムは、速い I/O パス または 送信バッファを通ります。デフォルトより大きめのデータグラムは、データグラムが実際に送られるまで保持されます。速い I/O とは、メモリのマッピングと I/O サブシステムを通る代わりに、データをコピーして I/O サブシステムのバイパスすることを意味しています。

このキーは、サーバーが配信できる最高のビットレートストリームよりも高い値にセットされるべきです。

付録 C: 実験から収集されたデータのすべて

次のパフォーマンスモニターの値は、Windows Media Server 用に実施したパフォーマンステストのために収集されました。

• CPU
• Allocated bandwidth
• NIC bytes sent/sec
• Working set
• Pool non-paged bytes
• Pool paged bytes
• Thread count
• Handle count
• Page faults/sec
• Interrupts/sec
• Context switches/sec

詳細情報

Windows Media Services 4.1 についての詳細情報は、Windows Media Services 4.1 のヘルプを参照してください。