優化Microsoft Windows Media Services 9 Series

本文在技術上提供了對Micorsoft Windows Media Services 9 Series的效能和可量化的概述（包括隨windows 2003 server一起釋出的WMS的升級版本）。本文表述了WMS效能方面的觀點、限制條件和效能監控技術。本文同樣展示了一組在可控的試驗環境下測試獲取得到的一組測試結果和資料。

筆者推薦將本文所提供的資訊作為一種指南。文中的測試結果是基於特定的硬體配置，它是是對現實世界場景的一種簡化。你的流媒體系統的真實能力取決與很多的因素，包括網路拓撲結果，使用者使用模式，硬體配置和軟體配置。基於本文提供的指南和效能資訊，你應該能夠來設計，調優和最大化你的伺服器能力，從而為你個人目標達到最好的效果。

本文包括如下的幾個主題：

l         基本指南：對搭建一個流媒體系統提供基本的指南。

l         WMS 4.1 VS WMS 9 系列： 比較兩個版本的WMS的特點和效能。

l         瓶頸：為一般的伺服器效能問題提供潛在的原因分析和解決方案。

l         效能評估： 解釋WMS 9 在一系列效能和壓力測試下如何表現。

l         高階調優： 提供額外的WMS 9的調優技術。

l         附錄 A-F： 有關於WMS 實驗室測試詳細的配置和結果。

l         更多的資訊：提供額外資源的資訊。

 

 

基本指南

為了保證你的使用者能得到最好的體驗，參考如下幾個基本的指南：

l         限制總的使用者數量為你在負載測試中所支援的最大使用者數的一半。

l         確保整體的網路利用率低於最大的網路卡容量的50%，或者低於支援普遍位元率的最大吞吐量的50%

確保你的伺服器有足夠可用的記憶體來支援一個理想的效能水平。

無論什麼時候儘可能使用專用的流媒體伺服器。避免執行額外的高耗CPU的服務，比如IIS或者SQL SERVER。

WMS 4.1 VS WMS 9 系列： 比較兩個版本的WMS的特點和效能

WMS 9系列對比於先前的4.1版本提供了顯著的效能提升。下面的列表包括了一些對WMS 9系列的效能增強有貢獻特色。

l         新的物件模型和擴充套件的外掛構架

l         改進了的I/O和執行緒模型

l         通過Fast Streaming技術改進了的使用者體驗。Fast Streaming技術是由四個元件組成：Fast Start，Fast Cache，Fast Reconnect和Fast Recovery。

l         更低的磁碟搜尋操作，由於獲取了更大的資料塊。

l         更多在一個普通場景中同時線上的使用者數

l         記憶體快取技術的使用，由於使用了windows server 2003所支援的檔案快取技術。

l         在UDP傳輸上更高的包恢復率。

l         支援Real Time Streaming Portocol（RTSP）

l         改進了的負載模擬測試工具（Windows Media Load Simulator 9 系列）

 

下面的幾個圖總結了由WMS4.1到WMS 9的效能提升。第一個圖展示了在兩個平臺上的最大廣播使用者數的對比。第二個圖展示了在兩個平臺是上的最大點播使用者數的對比，點播來源是在一塊 RAID 0 SCSI 3 15000 RPM的硬碟。第三個圖展示了在兩個平臺上的最大點播使用者數的對比，點播來源是一塊單獨的SCIS 3 15000 RPM硬碟。

 

 

Modem/Dial-up

 

 

DSL/Broadband

 

 

Intranet

 

 

 

瓶頸

當一個程式或者活動的一部分減慢或者阻止了其他部分，從而影響了總體的進展或者效能，這時瓶頸就產生了。在一個WMS系統中常見的瓶頸是CPU，資料來源的吞吐量，輸出的網路頻寬和系統記憶體。CPU使用率和系統記憶體瓶頸通常要比資料來源吞吐量和網路頻寬限制容易識別。

最為關鍵的是你需要識別、移除或者最小化你係統中的所有的瓶頸，從而最大程度上提高WMS的容量和終端使用者的使用者體驗。

 

CPU 計算效率

系統管理員傾向於相信這樣一種觀點：只要CPU使用率沒有達到100%，那麼他們的系統就是健康的。不幸的是，這種假定並不總是正確的。舉例來說，總是有這樣一些案例：伺服器即使是在CUP使用率非常低的情況下仍然不能接受更多的壓力。

有幾種其他型別的瓶頸並不是由於過高的CPU使用率引起的。這些瓶頸可能會明顯的降低終端使用者的體驗度，而並不需要影響伺服器的CPU使用率。通常來說，由於記憶體換頁而引起的系統記憶體瓶頸可能會導致CUP使用率達到100%。另外一方面，網路頻寬和資料來源吞吐量則通常不會影響到平均的CPU使用率水平。

你可以使用幾種不同的程式和工具來監控CUP使用率，包括：

l         WMS在MMC中的外掛。在這個外掛的detail 皮膚的Monitor頁上提供系統CPU使用率的資訊。

l         Windows工作管理員。

l         效能監控器："Processor(*)"% Processor Time 計數器提供更為詳細的CUP使用率資訊，比如圖表和歷史資訊。

 

為你的流媒體伺服器選擇正確的硬體需求，容量和CPU是非常重要的。平均的CPU使用率取決於使用者的操作，比如連線到一個流或者流檔案，在不同的播放列表之間切換，快進，搜尋，或者提交日誌。

有一個通用的原則，那就是平均的CPU使用率應該不要超過20%，並且併發的使用者數應該低於伺服器在支援特定的位元率的最大容量的50%。這個指導可能看起來有點保守，但是這是基於一個事實，那就是CPU使用率對於內部伺服器操作變化非常大。舉例來說：有一臺給幾千個穩定的使用者廣播的伺服器。依據位元率和伺服器，CPU的使用率很容易保持在低於20%的水平。但是如果幾百個使用者同時試圖去連線到伺服器或者切換到不同的播放列表，伺服器的CUP使用率可能在幾秒鐘內激增到一個較高的水平。通常來說，對成倍的使用者進行流傳輸要比處理單個使用者的請求消耗少的CPU。因此，保持CPU平均負載低於20%必不會對支援最大數量的流媒體使用者產生明顯的減少。剩下的75%的CPU容量可以用來處理更多高消耗CPU的使用者請求，從而減少相應時間和增強使用者體驗。快進和搜尋操作是兩種高耗CPU資源的例子，它們能夠獲得空閒的CPU週期的支援。

如果你發現你的伺服器的CPU使用率臨時達到一個比推薦值高的水平，這時可以

避免伺服器端實時播放列表的操作。

減少Connection rate（per second）limit。

減少Fast Start bandwidth per player limit。

作為一個基本的永久的原則，考慮升級你的硬體能力來減少平均CPU使用率水平和提供一個高質量的服務給你的使用者。

 

處理器數量

WMS 9系列很大程度上來依賴於I/O操作。因此，增加處理器的數量並不能有效的增加伺服器的處理能力。其他的因素，比如內部匯流排佈局，匯流排速度，網路介面匯流排位置，不同處理器之間的中斷處理分配和資料來源吞吐量容量都對整體的效能有重要的影響。

當WMS 伺服器使用1Gbps的網路卡，測試資料顯示雙處理器系統能在大多數的情況下提供很好的結果。當伺服器使用1Mbps的網路卡時，測試顯示單處理器伺服器能應付大多數情況下的負載。值得推薦的是，你可以使用4個或者以上的處理器的伺服器來對無線網路進行流傳輸或者使用高耗CPU的外掛。

下面的圖顯示伺服器在使用1/2/4/8個CPU的情況下，對22Kbps和300Kbps的RTSPU進行流傳輸的時候，伺服器所能支援的最大使用者數。粗略的說，在處理器數量線性增加的同時，連線的使用者數呈幾何數增長。這種行為主要是由I/O資源限制引起的。由於I/O的限制，增加的處理器能力並沒有完全被利用。對於更多測試中使用的8處理器的伺服器資訊，請參考附錄A（參考硬體編號S3）。

 

 

 

 

 

 

 

l         請依據以下指南來達到在處理器能力方面最優的伺服器效能：

l         限制平均的CPU使用率低於或者等於全部處理器能力的25%。

l         當流傳輸給成倍使用者時，避免執行高耗CPU的操作。

l         如果你的CPU使用率高於正常的水平，請儘可能多的關閉程式，包括WMS在MMC總的外掛。

 

資料來源吞吐量

WMS 9 系列支援很多種流媒體資料，支援內建和非微軟資料來源外掛。預設安裝的WMS包括一組外掛，這些外掛能夠提供對網路內容（從其他WMS或者encoder傳輸的流媒體檔案），HTTP下載和檔案資料來源（儲存在本地或者遠端檔案系統）。
    為了保證一個良好的使用者體驗，在不考慮資料來源的情況下，確保伺服器和資料來源之間的連線能夠維持所需要的資料傳輸率。資料來源可以是簡單的儲存在本地的流媒體檔案。更多複雜的資料來源包括從分散式伺服器傳輸的流媒體或者儲存在NAS和SAN上的流媒體檔案。根據資料來源和伺服器之間的連線方式（架構，驅動器，等等）的不同，最大的吞吐量和對伺服器CPU的利用率變化非常大。對於這些不同的解決方案的特定的效能測試結果和比較並不是本文討論的範圍。請與你的儲存方案供應商確認最大可支援的吞吐量和對CPU使用率的影響。

釋出點型別對於決定你的資料來源吞吐量需求是一個關鍵的因素。廣播發布點要比點播發布點更少的資料來源消耗。在任何給定的時刻，連線到廣播發布點的使用者都會收到一份相同資料的拷貝。通常來說，一個廣播發布點從資料來源接受到一份資料後分割然後分發給所有的使用者。相比較，點播發布點則需要為每個使用者連線直接進行讀資料，從而導致資料來源負載的增加。

會有一些這樣的情況，一些點播使用者會經常範圍一些非常受歡迎的檔案。為了提供這種情況的效能，內建的WMS檔案資料來源外掛會利用Windows server 2003作業系統的檔案快取功能。這樣，如果一些點播的使用者頻繁訪問同一個資料來源，WMS會從伺服器的快取的獲取資料而不是從原始的資料來源檔案。這樣就能明顯的幫助減輕資料來源吞吐量的需求。預設的情況下，當資料來源來自本地NTFS或者FAT檔案系統時候，WMS會利用檔案快取功能。檔案快取功能對其他儲存系統的檔案型別的支援取決於驅動器的實現。請和你的儲存解決方案供應商確認是否他們的解決方案支援Windows server 2003的檔案快取技術。

 

下面的圖顯示了PhysicalDisk（_Total）"Disk Read Bytes/sec 和Windows Media Services"Current File Read Rate(Kbps) 兩個計數器的對比，分別使用RTSPT協議來傳輸22Kbps和300Kbps的流媒體。這些圖描述了一個理想的場景，那就是所用的使用者都從一個單個的內容接受點播流。在這個場景中，WMS從內建的檔案資料來源讀取的總量呈線性增長，而同時從磁碟獲取的總量卻大概維持穩定和幾個較低的水平。

 

 

 

 

 

你可以觀察幾個效能指標來診斷不同資料來源層次的狀態。最主要用來衡量資料來源瓶頸的計數器是：Performance Monitor"Windows Media Services"Current Late Read Rate。這個計數器，適用於伺服器和釋出點級別。指示當前那些完成了但是有延遲的讀操作的數量。你可以在釋出點級別使用這個計數器來判斷特定的發表點是不是有讀延遲現象。

 

如果這些計數器的值在一段時間內大於0則表示一個或者多個發表點正經歷資料來源吞吐量的問題。在這種情況下，你可以使用"Windows Media Service"Current File Read Rate(Kbps) 和"Windows Media Service"Current Incoming Bandwidth（Kbps）計數器來確定進來的資料率。對於伺服器的資料來源，你可以適用特定的計數器比如：Local File System"Physical Disks, Network Data Source"Network Interface 和Remote File System"NTB connections來確定那些網路介面正處在一個什麼樣的水平。如果你發現資料來源使用的一個或者多個介面對系統的瓶頸有責任的話，你可以考慮對它們進行升級，加多更多的資源，或者將負載分佈到不同的伺服器上去。

 

資料來源能夠被分割為3組型別：本地快取（在記憶體中），遠端快取，和不快取。

 

本地快取（在記憶體中）的情況發生在當大多數的使用者都訪問一小部分流媒體檔案時。增加更多的使用者的話通常會導致更多的記憶體使用和CPU使用率。根據這種使用的資料來源，這樣的增加並不會導致讀延遲。另一方面，伺服器CPU使用率達到一個較高的水平，並且"Windows Media Services"Current Late Send Rate 計數器增加並超過0。這種結果是典型的由CPU瓶頸所導致的，下面會有一個章節詳細討論這個問題。本地快取的一個常見的例子就是大多數的使用者訪問一個儲存在本地檔案系統的檔案。

 

遠端快取或者無快取的情況發生當多使用者訪問多檔案的時候。在這種情況下，無論檔案內容是否被遠端快取或者根本沒有被快取，當伺服器和資料來源之間的連線達到吞吐量的限制或者資料來源的容量已經達到極限，讀延遲就發生了。NAS和SAN架構遠端快取很好的例子，這種情況下，最大的吞吐量取決於網路狀況或者私有介面的容量。不快取的例子則是多使用者訪問儲存在本地的多流媒體檔案，這種情況下，最大的吞吐量通常取決於磁碟或者磁碟介面的容量。

 

     在很多案例中，流入的資料來源連線和流出的流傳輸共享相同的網路卡。我們不推薦這種配置，因為這樣會很容易使網路卡產生吞吐量瓶頸。

 

     所有在本文中出現的點播的效能測試都是使用的單個儲存在本地NTFS檔案系統的流媒體。選擇這種本地快取的方式是為了證實WMS所能支援的最大容量，而不受任何資料來源硬體的限制影響。在點播並沒有快取的情況下，這時WMS所支援的容量取決於資料來源的硬體配置和吞吐量能力。在多播中當客戶分發的情況增加時，由於快取命中率的減少會產生多餘的資料來源容量。附錄B記錄了一系列的效能測試結果。使用硬體S1和S2的配置，WMS可以支援22000個以22 Kbps釋出的流，而吞吐量大概在470 Mbps。另一個測試結果表明WMS能夠支援990個以1 Mbps釋出的流，而吞吐量大概在970 Mbps。

    

     下面的指南能幫你減少在資料來源上有限制的系統上的瓶頸。

l         避免將流媒體檔案儲存在作業系統所在的磁碟。

l         在流媒體所在的磁碟禁止頁交換操作。

l         在任何時候如果可能的話，儲存流媒體的本地磁碟或者儲存系統支援Windows Server 2003的檔案快取技術。

l         在多伺服器環境裡，如果資料的容量和更新頻率沒有被禁止的話，在所有的伺服器之間複製流媒體檔案。如果複製資料不是最有效率的話，分割資料並在多伺服器上存放和傳輸。

l         當遠端儲存檔案時，避免在同一個連線上進行流入和流出的傳輸，為每個任務使用獨立的介面。

l         不要從HTTP源來重新獲取資料。只使用HTTP來進行動態播放列表的處理和獲取。

 

 

高階 FF/RW

包含在Windows Media Server 2003 SP1裡面的WMS的升級包裡面包含高階FF/RW 媒體程式外掛，它能夠幫助減輕在使用者提交快進或者快退請求時所產生的資料來源瓶頸。這種外掛在高位元率傳輸的場景的時候非常有效，比如在IPTV系統中進行點播傳輸。使用這個外掛，內容提供方需要將檔案在多個FF/RW比率上進行編碼。然後這些檔案這些檔案才能在使用者以欺騙模式傳送請求的時候被訪問。更多的資訊，請參閱WMS的幫助檔案中'理解高階FF/RW'一節。

 

    有這樣一個案例，一個使用者以普通的速度播放60s，然後以5倍的速度快進60s，最後恢復普通速度回放60s。下面的圖顯示了WMServer.exe 程式的I/O Read Bytes/sec的資料情況。

注意到使用高階FF/RW的時候，byte read要明顯的低。當很多使用者同時使用快進模式的時候，此外掛能夠很大程度上減少後端資料來源的傳輸。

 

頻寬

造成頻寬瓶頸的兩個主要的方面是伺服器網路卡的總體容量和伺服器之間、伺服器和使用者之間的網路拓撲和容量。本文不討論第二個方面，因為大部分的變動的原因超出了WMS的控制範圍。

 

兩種最常見的網路卡的傳輸速度為100Mbps和1Gbps。在硬體的支援下，WMS能夠使用網路卡95%容量。

 

使用典型的伺服器配置，使用一小部分CPU資源WMS就能夠達到單個100Mbps網路卡的極限。因此，本文重點會放在使用1Gbps的網路卡所獲得的效能測試結果上，而不會討論使用一個或者多個100Mbps的網路卡的伺服器配置。

 

為了使用WMS獲得最大的全域性吞吐量，我們推薦使用1Gbps的網路卡。使用1Gbps的網路卡能得到非常好的結果，可以單個伺服器的吞吐量水平達到960Mbps。當在硬體S1和S2上使用2個或2個以上的網路卡，CPU的使用率便成為了限制因素。儘管如此，在效能測試中，當使用2個1Gbps的網路卡的時候，WMS能夠達到高於1.3Gbps的吞吐量水平。

 

計算器"Windows Media Services"Current Late Send Rate是評估網路瓶頸的相關的效能計數器。每當WMS傳送的資料包比預定的傳送時間延遲最少1.5s，WMS便報告一次late send。Late read可能由於可用的頻寬不能滿足所有的使用者，也可能處理器時間週期的短缺，也可能是原始的資料來源的原因。第二和第三並不與網路瓶頸相關。為了確認網路瓶頸是不是late read產生的原因，需要考慮如下幾個因素：

 

持續時間少於5s的late send通常表明伺服器臨時過載或者不能及時地獲取資料來源資料。客戶端快取有足夠的資料以維持回放直到伺服器的流媒體恢復到正常水平。通常導致系統臨時過載的原因是有新的客戶連線，或者大量同時的客戶請求（比如搜尋，快進等等）或者是在 廣播時服務端播放列表的轉換。如果系統過載是由於客戶活動，可以考慮減少連線頻率限制和保留多餘的CPU資源用來處理客戶請求。

 

持續超過10s的late send並且伴隨較低的CPU使用率和無late read的情況通常表明有對外的網路瓶頸。檢查"Windows Media Services"Current Player Allocated Bandwidth(Kbps) 和"Windows Media Services"Current Player Send Rate(Kbps) 兩個效能計數器來確定是否是late send導致的網路瓶頸。分配的頻寬和實際使用者使用的send rate之間的差異表明客戶接受資料的速度不足夠快。注意網路瓶頸還可能由本地介面的限制或者發生你的網路之外的其他遠端頻寬限制所引起。在這種情況下，有可以遵循以下做法：增加你的網路介面和外部網路容量，限制最多的使用者數量，或者增加更多的流伺服器。如果你不願意改變伺服器配置，那麼網路瓶頸則有可能會影響到使用者回放的質量。

 

持續超過10s的late send並且伴隨較低的CPU使用率和持續的late read的情況通常表明伺服器不能足夠快地從資料來源接受資料。這是典型的資料來源瓶頸。只有那些連線到收late read影響的發表點的使用者才會出現回放問題。而連線到其他發表點的使用者可能能夠正常接受資料而不會有回放的問題。

 

   持續的late send 並伴隨非常高的CPU使用率，不管有無late read，通常表明伺服器上的一種或者多種資源已經耗盡。在這種情況下，很多使用者會有回放的問題。這是典型到由於CPU或者記憶體瓶頸而引發的例子。在這個案例中，你應該減少最大使用者數或者增加更多的伺服器來均衡負載。

 

下面的指南能幫助你優化伺服器效能和減少網路相關的問題：

l         使用Windows Media Load Simulator 9系列進行效能測試來確定你的伺服器的最大容量和建立合理的限制。

l         限制總體的使用者頻寬為最大網路頻寬的50%或者最傳輸普通位元率時的總體頻寬的50%，或者更低。要獲得限制和位元率總體頻寬的更多資訊請參見'限制'一節和附錄B。

l         使用1Gbps的網路卡來最大化你的伺服器容量，多播的情況除外。

l         使用獨立的網路卡來傳輸流入和流出的資料，如果內容是遠端儲存的話。

l         確保網路卡和網路構架支援全雙工傳輸。

l         如果你的網路架構執行，在廣播點啟用多播流傳輸。

 

系統記憶體

 

有幾種工具可以用來跟蹤系統記憶體，包括Windows工作管理員和效能監控的"Process(WMServer)"Private Byte 計數器。作為一個通用原則，系統記憶體應該總是要比WMS的程式（WMServer.exe）使用的記憶體要多。理想的情況是，對於多播的情況，WMS伺服器應該具備比達到目標播放效果至少多30%的記憶體。而對於點播的情況，我們推薦至少要多出50%，因為作業系統需要使用更多的記憶體來進行檔案快取操作。

 

每個使用者的平均記憶體取決於釋出點的型別和內容的編碼設定，比如位元率，包大小和音訊、視訊流的數量。請參看附錄B以獲取更多有關每個使用者平均記憶體需求的資訊。根據使用模式，目標使用者數，客戶在不同釋出流中的分佈和不同的發表點型別，你要能夠估算出你的流媒體系統需要多少記憶體。

 

如果你的伺服器有足夠多的實體記憶體，多餘的記憶體能減少由於記憶體換頁導致的延遲從而增加伺服器整體的效能。作為流媒體的特性，WMS使用一個小的時間視窗來傳送資料到所連線的使用者。一個記憶體緊張的系統裡面，當伺服器處理，傳送或者從資料來源讀取資料的時候，記憶體換頁操作可能引起不可預料的延遲。Late send的結果通常會影響到整體的客戶體驗度。如果伺服器有足夠多的可用記憶體，作業系統能最大程度的利用檔案快取從而減少資料來源吞吐量瓶頸造成的影響。

 

有幾個決定系統記憶體需求的因素。舉例來說，廣播發布的流通常需要比點播發布的流較少的記憶體。連線協議同樣也對整體佔用的記憶體有影響。通常來說，基於TCP的協議需要的系統記憶體少於基於UDP的協議，因為WMS需要為UDP連線儲存額外的資訊。依據不同的位元率，WMS需要在伺服器記憶體中儲存最多10s的傳送資料用來滿足包的重新傳送請求（當UDP包在傳輸過程中丟失）。需要了解更多WMS支援的協議和之間的效能區別，參見本文'協議'一節。

 

依據不同的位元率，點播使用者連線需要3-10倍於廣播連線的記憶體。另外，使用UPD協議的點播連線通常需要2-3倍使用TCP協議的連線。在實踐中，一臺4G記憶體的伺服器最多支援22800個22Kbps的廣播音訊流和最多22000個22Kbps的點播音訊流。

 

和其他的32位應用程式一樣，WMS有一個記憶體的極限，這個極限限制了伺服器最大的容量。如果WMS程式記憶體使用達到2G，參看本文'伺服器名稱空間設定'一節來獲知如何減少每個使用者的平均記憶體使用。

 

下面的指南能抱著你優化伺服器效能：

l         根據目標效能水平和客戶分佈模式來計算所需的最優化的記憶體容量。

l         提供高於WMS進行廣播而需的記憶體容量30%的系統容量。

l         提供高於WMS進行點播而需記憶體容量的50%的系統容量，從而最大化檔案快取容量和較少記憶體換頁操作。

l         確保WMS使用的記憶體不會超過系統全部的實體記憶體。

l         保持WMS使用的記憶體水平低於2G。如果記憶體使用達到2G, 退出並重啟WMS, 獲知通過其他的伺服器來均衡負載。

 

效能評估

 

本節介紹WMS 9在一系列效能和壓力測試下是如何表現的。本節談到的是一個測試引數的列表，一個對WMS極限的解釋和最大化你的WMS伺服器的指導。本節也同步展示了很多的圖表，這些圖表展示了WMS在不同的測試場景中傳播22Kbps和300Kbps的資料流的可度量的測試結果。

本節包含如下的主題：

l         協議

l         位元率

l         直播VS點播流

l         快進流

l         無線

l         播放列表

l         限制

 

協議

WMS支援3種不同的unicast流媒體協議：Real Time Streaming Protocol（RTSP），Hypertext Transfer Protocol（HTTP）,和Microsoft Media Server Protocol（MMS）。RTSP和MMS均可以以TCP或者UDP的形式傳輸。本文使用以下的約定的名稱：RTSPU(RTSPover UDP), RTSPT(RTSP over TCP), MMSU(MMS over UDP), MMST(MMS over TCP)。HTTP只能在TCP上傳輸。

 

WMS也支援多播流媒體。當多播的使用者增加時，對伺服器的效能沒有明顯的影響，因為多播客戶是連線到流媒體而不是伺服器。理論上，一個WMS伺服器能夠支援無限制的多播使用者數。因為多播流媒體對伺服器效能沒有很大的影響，本文將不會討論多播的效能問題。

 

談到效能，協議能分為2個主要類別：基於TCP的協議（TRSPT,HTTP,MMST）和基於UDP的協議（RTSPU,MMSU）。效能測試結果表明，平均來說，WMS使用基於TCP的協議要比使用UDP的協議支援更多的流的數量。接下來的圖表明瞭WMS在使用不同的協議的情況下所能支援的22Kbps和300Kbps的最大連線數

 

 

 

 

 

 

當一個使用者連線到WMS時，URL的字首決定了WMS使用哪種協議來進行流傳輸。如果URL使用預設的mms://字首，那麼使用者和伺服器則自動協商使用最有可能的協議。每種協議均有其優點和侷限，並且一些協議比其他的協議在某些情況下更合適。舉例來說，防火牆或者代理伺服器可能會阻止使用某種協議來傳輸資料。在這種情況下，使用者和伺服器則自動通過協商建立起使用某種協議能通過防火牆或者代理伺服器的連線。因此，我們特別建議為了更好的效能，請不要禁止任何協議的使用。

在一個典型的流媒體釋出系統中，你需要支援併發的資料流通過所有的協議。因此，你能夠通過評估客戶在每一個特定的協議上的傳輸負載來哦判斷伺服器的容量。

 

下面的有關協議的指南能幫助你優化你的伺服器效能：

l         總是使用預設的mms://字首來作為連線的URL。這樣能夠使使用者和伺服器自行決定最有效的協議。

l         無論什麼時候可能的話，使用HTTP協議。這種協議在防火牆或者代理伺服器阻止RTSP和MMS協議的情況下非常有用。

l         指定一種基於TCP的協議，比如RTSPT或者HTTP，用來當伺服器自己連線時候減少資料丟失，比如在一個分散式或者快取/代理的情況下。

 

位元率

數字媒體檔案的位元率，通常以Kbps來計量，會影響到WMS的效能和連線到流媒體的最大使用者數。你可以用媒體檔案的位元率與使用者數相乘來得到流經伺服器的總體資料流量。這種合計的位元率直接影響網路吞吐量，CPU使用率水平，記憶體‘footprint’和資料吞吐量。當媒體檔案的位元率增加時，最大使用者數相應減少。這兩者之間的關聯總是線性的。在不同的位元率條件下不同的瓶頸限制了伺服器的最大容量。舉例來說，當傳輸低位元率解碼的媒體檔案時，伺服器通常遇到系統記憶體和CPU瓶頸，比如在8Kbps和22Kbps之間。另一方面，傳輸高位元率的媒體檔案時，比如500Kbps，最大使用者數通常受網路吞吐量瓶頸的限制。

 

附錄B展示了一組全面的效能測試結果，它們揭示了一個WMS伺服器在傳輸從22Kbps到1Mbps的媒體檔案時的指標的度量情況。下面的圖選取了一部分結果資料，位元率從22Kbps到300Kbps。這些圖展示了使用RTSPU和RTSPT協議的指標對比情況，測試指標有：Processor(_Total)"% Processor Time, Process(WMServer)"Working Set, Windows, 和Windows Media Services"Current Player Send Rate（Kbps）。

 

 

 

 

 

 

 

 

 

 

複合位元率媒體檔案（Mutiple-Bit-Rate）

以複合位元率編碼的媒體檔案導致在一個單一的檔案或者流裡面包含有音訊，視訊，或者腳步幾個流的組合。每個單獨的流通常都有一個不同的位元率。當使用者連線到一個複合位元率（MBR）的流，播放器播放的最合適的流的集合則依據媒體內容的位元率和合適的頻寬。

 

有這樣一個包含3個視訊流（流A—285Kbps，流B—135Kbps，流C—20Kbps）和一個音訊流（流D—15Kbps）的MBR場景。當使用者連線到這樣的流媒體上時，使用者有如下的選擇：A+D(300 Kbps), B+D(150 Kbps),C+D(35 Kbps), D(15 Kbps)。舉例來說，一個56 Kbps調變解調器的使用者，將最有可能看到C+D流，而一個28 Kbps的使用者則被限制去訪問流D。

 

自動速度探測和流選擇是使用MBR的關鍵優勢。這個特點可以提供更好的使用者體驗而不需要為不同位元率的流搭建多個釋出點。而另一方面，由於使用MBR導致的每使用者記憶體佔用和資料來源負載，伺服器的效能可能受到影響。這種行為發生是因為伺服器需要為所有的流組合（A+B+C+D）來獲取、分配記憶體和處理資訊，而不論那個一個流被選擇到。結果你的系統就會很有可能在進行MBR流傳輸過程遇到記憶體或者資料來源吞吐量瓶頸。當多個使用者都連線到相同的流，Windows Server 2003的檔案快取特點能夠幫助緩和這種限制和使得伺服器能夠支援更多的流同時傳輸。

 

一個簡單的確定伺服器進行MBR流媒體傳輸的總體能力的方法就是考慮所有組合的流的情況下計算記憶體和資料來源瓶頸值。

 

可變位元率媒體內容（VBR）

WMS提供對VRB流傳輸有限的支援。WMS使用快速快取技術在一個固定的位元率來傳輸VRB流，該位元率要足夠高從而避免客戶端的重新快取。因為VBR流傳輸的支援是在WMS 9系列平臺下引入的，因此VBR流傳輸只能在Windows Media Player 9，WMS 9,和Windows Media codecs 9 一起組合使用的情況下進行。和使用MBR一樣，你也可以通過計算在實際固定的位元率快速快取傳輸資料的情況下的極限來確定大體的伺服器處理能力。

 

媒體檔案編碼設定

編碼設定，比如包大小，快取大小，和關鍵幀間隔通常對於伺服器和終端用來說都是透明的，因為這些設定是在媒體檔案生成的時候就設定好的。即使WMS不能夠控制這些設定，他們仍然會對整體的伺服器能力有影響。特定的編碼建議並不是本文討論的範圍，但是請在決定如何設定編碼配置的時候考慮如下基本的指導意見：

l         無論什麼時候可能的話，以小於1452位元組的包大小來編碼。這樣的話，當包被組裝上標頭檔案資訊後，它們將可以存放在一個單一的最大傳輸單元裡面（1500位元組）。請注意對於RTSP連線來說，這一點可能不需要，因為伺服器能夠自動調節包大小。

l         設定2-4s的快取大小來減少開啟延遲和搜尋反應時間。請注意減少快取時間可能會影響到編碼的質量。

l         當設定編碼器來進行現場流媒體傳輸時，設定關鍵幀間隔少於8s來減少在廣播時候的開啟延遲。

 

下面是一些基本的指南，可能在位元率方面能幫助你優化效能：

l         使用最適合你需要的位元率和解碼器。舉例來說，即使你的使用者擁有高速連線，也不要以2Mbps的位元率來解碼如果500Kbps的位元率就能滿足你的質量需求。

l         當使用者在以一個很大訪問的位元率來訪問相同的流媒體，則使用MBR進行編碼從而最大化使用者體驗和減少設定的複雜程度。

 

 

直播VS點播

前面我們討論過直播和點播流的效能區別。廣播流通常要比點播流使用少的資源，因為廣播發布點在多個使用者之間共享記憶體和資料來源，而點播發布點則必須為每個連線的使用者分配記憶體和資料來源資源。

下面的圖表展示了廣播發表點和點播發表點使用RTSPU和RTSPT協議傳輸22Kbps和300Kbps流媒體的時候計數器Processor(_Total)"% Processor Time, Process(WMServer)"Working Set, 和Windows Media Services"Current File Read Rate(Kbps)的情況。

 

 

 

 

 

 

 

從上面的圖可以看出，RTSPT的表現要好於RTSPU，並且廣播要比點播需求少的資源。參見附錄B以獲得更全面的效能測試結果，包括最大伺服器容量和推薦的利用水平等細節。附錄B的矩陣中覆蓋了所有的協議，一般的位元率好釋出點型別。同樣也展示了使用了修改的名稱空間設定而獲得的點播效能測試結果。

 

快速流媒體

快速流媒體提供了一種即時地、一直線上的流媒體播放體驗，它通過有效地減少緩衝時間和降低由於網路條件所引起的中斷的可能性。快速流媒體由四個元件組成：

l         快速緩衝提供比流媒體規定的快的速率講流媒體內容傳輸給客戶。

l         快速開始提供比請求的位元率更高的速度來達到初始的快取。

l         快速恢復提供一種方法，能夠不需要客戶請求重發而自動恢復那些丟失或者損壞的資料包。

l         快速重連允許自動在網路中斷後重新連線到伺服器和重新開始流傳輸。

 

通過快速開始，伺服器以高於請求的位元率速率傳輸資料到客戶端快取。這使得使用者更快地能夠開始接收和提交內容。釋出點只是在初始的快取需求被滿足後才開始以預定的位元率傳輸內容。相應地，建立一個快速開始的連線的網路使用率會比建立一個普通的連線要高一些的。它們之間的區別在很多使用者在同一時間連線到流媒體的時候才會很明顯，因為這時的連線時間相比總的流傳輸時間會很小。為了最大化使用者對快速開始的體驗，遵循下面的指導，特別是那些關係到網路和CPU的儲存。

 

為了計算快速開始對特定使用者場景的影響，可以使用下面的公式：

 

       這裡

 

 

舉例來說，通過56Kbps的調變解調器連線來傳輸電臺流媒體。假設56Kbps的調變解調器能夠達到大概45Kbps的的吞吐量，假設音訊內容是以22Kbps速率解碼，那麼快取的時間將會從5s（使用傳統的流播放）減少到2.4s（使用快速開始）。如果是使用700Kbps的DSL連線，那麼快取時間將會更小，大概15ms。在這兩個案例裡面，使用快速開始功能的使用者體驗將比不啟用快速開始功能的要好很多。

 

下面的圖顯示了當使用者連線到一個300Kbps的廣播流時計數器Processor（_Total）"% Processor Time 和Windows Media Services"Current Player Send Rate(Kpbs)的表現。開始時，沒用客戶連線到流媒體，8s後，180個使用者同時連線並保持連線，20s後另外180個使用者連線到該流媒體。

 

在一個圖裡面，無論是否啟用快速開始，當客戶連線的時候，CPU的佔用水平會短暫地增長。第二個圖顯示網路佔用水平達到穩定的所期望的水平前維持一段時間的高於一般的水平。網路佔用量的峰值為持續幾秒，如果幾個同化同時連線到流媒體的話。對單個連線的影響通常會更小和持續小於1s。

 

 

 

 

快速快取提供一種方法可以使得將內容以快於特定的流媒體速率的速度傳輸。舉例來說，當快速快取啟用的話，伺服器能夠以500Kbps的速率傳輸一個100Kbps的資料流。WMS播放器仍然會以原來特定的速率播放流，但是播放器能夠在播放前快取一大部分內容。快速快取只工作在點播流。使用快速快取會影響到效能和減少同時連線的最大使用者數，同是資料來源和網路頻寬使用率也會增加。從效能的觀點來看，如果使用快速快取來以500Kbps的速率傳輸100Kbps的流媒體所需要的系統和網路資源將和不使用快速快取來傳輸500Kbps所需求的一樣多。

 

儘管快速快取可能需要更多的每使用者資源使用量，但是這種使用量會隨時間而減少，因為一個快速快取的客戶連線持續的時間只是一個非快速快取連線的一小部分。舉例來說，以500Kbps來傳輸一個2分鐘，100Kbps的片段將會傳輸30s，在真實時間裡，相同的流媒體傳輸會需要2分鐘的網路使用。通過一段特定的時間，從你的伺服器傳輸的總體的資料量會是一樣的，無論是否啟用了快速快取。不管怎麼說，仍然極力推薦你啟用快速快取功能，因為它使得連線根據時候網路頻寬的波動，從而提供更好的使用者體驗。

 

下面圖展示了不使用快速快取向100個客戶傳輸2分鐘，100Kbps的流和使用快速快取傳輸以5倍的速率傳輸同樣的流媒體的計數器的不同表現。在第一個圖裡面，在使用者量很小的時候，CPU佔用率（"Processor(_Total)% Processor Time）的區別是很小的。第二個圖顯示，當快速開始啟用時，總體的吞吐量（"Windows Media Service"Current Player Send Rate(Kbps)）是大概5倍和持續時間只有不使用快速快取的時間的20%。第3個圖顯示使用快速快取的客戶（"Windows Media Service"Current Streaming Player）結束流傳輸內容和從伺服器斷開的速度會更快一些。

 

 

 

 

 

下面的指南能夠幫你優化使用快速流媒體的時候的效能：

不要改變預設的快速流媒體設定。他們被配置為提供最可能最好的使用者體驗。

增加預設的Fast Start bandwidth per player(Kpbs)限制值，當在區域網環境流傳輸高位元率的內容（700Kbps或者更高）。使用5倍於目標內容位元率的值作為基線值。

 

 

 

無線

你可以使用WMS快速恢復功能來提高終端使用者中無線場景中的使用者體驗。為使用快速恢復，你必須啟用釋出點上啟用向前錯誤修正功能（FEC）。FEC是一種普遍使用的方法，用來保持傳輸中不穩定或者慢的網路連線上的資料的完整性。當FEC啟用後，伺服器會傳送出多餘的資料，這些資料用來重建那些可能中傳輸到客戶端時丟失的資料包。這些冗餘的資料包可以使得客戶端重組原來的傳輸資料，即使有很大一部分資料包丟失。伺服器根據連線過程中由客戶端提交的一些引數來獲得這些冗餘的資料包。無線傳輸的支援只有當客戶端與伺服器端連線使用RTSPU協議的時候才工作。

 

使用FEC的無線流媒體傳輸會對CPU效能、記憶體佔用和網路佔用有影響。這些超出的影響的度量取決於客戶端提交的引數。測試結果顯示，使用預設的伺服器名稱空間的配置，即使用高的恢復率，設定50%的FEC(舉例來說，WMFecSpan=4, WMFecPktsPerSpan=2 & WMThinning=0) ，會有對系統資源有以下的影響。

 

l         最大的客戶端數量減少40%

l         網路佔用增加50%

l         平均每個使用者記憶體佔用記憶體增加30%到70%之間

 

增加的資源佔用只有當客戶端具體設定FEC引數的時候才發生。簡單地在釋出點啟用無線支援並不會導致任何明顯的效能降低。附錄B提供來更詳細的有關伺服器效能中典型的FEC位元率（32"64"128Kbps）上的細節。

 

下面的指南可能幫助你優化伺服器效能，當使用無線網路傳輸流媒體的時候：

l         只有當客戶端需要FEC的時候啟用無線支援。

l         決定採用儘可能低的FEC設定來保證必須的恢復速率，並據此來配置相關設定。

l         使用高於需要的設定可能會對系統產生不需要的要求。

l         使用有四個或者更多處理器的高效能伺服器來支援由於無線流媒體傳輸而增長的CPU和記憶體佔用的需求。

如果所有的連線到你的伺服器的客戶都準備使用FEC，那麼通過降低MaxResendBufferSizeSecs的名稱空間的設定為0來禁掉UDP重發功能。這種改變降低了分配給每個使用者的記憶體。更多的資訊，參見'伺服器名稱空間'章節。

 

 

播放列表

 

播放列表提供了一種方法，把多更數字媒體的片段組織到一個單一的列表裡面。WMS同時支援客戶端的播放列表和伺服器端的播放列表。客戶端的播放列表通常有播放者或者web指令碼建立並被儲存為.asx為副檔名的WMS檔案。服務端的播放列表通常有內容的製作者、伺服器管理員或者web頁面指令碼來建立並被儲存為.wsx副檔名的WMS檔案。

 

兩種型別的播放列表都會影響伺服器效能和資源佔用。對伺服器最有可能產生影響是當客戶端中播放列表元素之間傳輸的時候。WMS和客戶端必須在每次播放列表從一個元素切換到下一個元素的時候對新的流媒體傳輸設定進行協商。這種型別操作的花銷等同於一個新的客戶端連線。而當伺服器從一個播放列表入口開始流媒體播放時，對伺服器端的效能沒有明顯的不同。

 

當流媒體播放列表的時候，在釋出點型別和服務容量之間有一種很強的聯絡。當播放列表是從一個點播發布點進行流媒體的時候，客戶端的操作都是依時開展的。因為不可能很多客戶端在同一時間連線到釋出點，像播放列表傳輸這種消耗資源的操作也在不同的時間點上發生。當播放列表上從一個廣播發布點進行流媒體的時候，相反，傳輸幾乎是同時發生的。作為結果，伺服器的CPU效能佔用會中廣播過程中明顯增加，因為由於播放列表傳輸，更多的客戶請求需要來處理。

 

下面的圖表揭示了"Porcessor (_Total)"% Processor Time, System"Context Switches/sec &"Windows Media Service"Current Player Send Rate(Kbps) 等效能計數器中播放列表傳輸中的影響。在這個例子中，流媒體使用RTSPT協議傳輸到1000個廣播客戶。這些圖顯示了在3段22Kbps，60s播放列表元素中傳輸的2個轉換的過程。

 

 

 

 

 

 

 

 

下面的指南可能會幫助你優化伺服器，當使用客戶端或者伺服器播放列表的時候。

l         無論什麼時候可能的話，使用小的伺服器端播放列表（50個元素或更少）來進行點播，從而減少每個用的記憶體佔用。

 

l         如果你計劃中廣播的時候使用包含多個元素的播放列表，限制全部的使用者不超過最大數的20%。

 

l         將.wsx檔案儲存到你的本地檔案系統來減少客戶端連線的延遲，因為如果伺服器需要從HTTP資源來獲取這些檔案。

 

 

限制

 

你可以使用限制來得到你的WMS伺服器的效能邊界。通過調整限制值，你能夠確保你的傳輸不會超過你的伺服器、網路、聽眾的容量。極力建議你在釋出WMS到生產環境的之前評估系統的容量並對伺服器限制設定合適的值。你可以根據具體的需要中伺服器級別和釋出點級別來設定限制。

 

下面是一些你能夠中WMS中配置的限制引數：

l         限制播放使用者連線。 極力建議你將這個限制值設定為一個合適的值，而不要設定為預設值（Unlimited）。根據你的硬體配置，流傳輸場景和系統需求，設定一個最大播放使用者連線數。

l         限制外部分發伺服器連線數。確定你的系統需要多少分發伺服器併合理設定該限制值。不要保留該值為（Unlimited）。

l         限制合計使用者頻寬（Kbps）和限制合計的外部分發頻寬（Kbps）。總是設定這些限制值為100%。你不應該使用這些限制值來保持你的網路佔用水平低於50%。設定這些值過低的話會影響到網路佔用水平和快速流傳輸的功能性。你應該通過限制最大使用者連線數來使網路佔用水平保持在50%以下。

l         限制每使用者每流播放的頻寬和限制每外部分發流的頻寬。你能夠使用這些限制的預設值。你也能設定這些值等於每使用者快速開始頻寬或者最高流傳輸位元率，這個值可能會高一些。

l         限制連線速率（每秒）。設定這個值小於或者等於50使用者每秒。該限制幫助用來確保現有的連線不會受到不利的影響，當有大量新客戶連線到伺服器的時候。它同樣也保證使用者連線到流媒體時候獲得比較好的體驗。效能測試結果顯示設定該限制值為50個客戶每秒能夠在大多少情況下提供最優的效果。

l         限制進來的頻寬。確定你的系統需要的進來頻寬的容量併合理設定該限制值。不要保留為Unlimited。

l         限制使用者超時暫停（s）和限制連線確認（s）。你可以使用這些限制的預設值。更多的有關這些限制的資訊，請參閱WMS幫助檔案。

l         限制每使用者快速開始頻寬。該值只能設定在釋出點級別。你可以使用預設值。當中本地區域網傳輸高位元率的內容時，你才能夠增加該限制值。

l         限制快速快取內容釋出率。該值只能設定在釋出點級別。你可以使用預設值。如果伺服器由於大量併發的使用者而超載時候你應該減少該值，在點播的情況下。

 

高階調優

TCP/IP 登錄檔鍵

Windows Server 2003使用FastSendDatagramThreshold登錄檔鍵來決定一個資料包在發生操作中是應該通過快速I/O路徑還是應該被快取。快速I/O意味著伺服器繞過了I/O子系統並直接拷貝到網路卡的快取。

 

FastSendDatagramThreshold的預設值上1024。如果資料包的數量超過這個值，額外的操作就不可少了。結果是，CPU佔用和內容切換增加，同時伺服器能夠支援的併發最大使用者數減少。效能測試結果顯示調高這個預設的初始值能夠改進伺服器效能。

 

通常，只有高位元率的流媒體才會受到這個值改變的影響。大於1024位元的包通常會出現中位元率高於100Kbps的內容中。改變該值一個副作用就是會導致分配給伺服器的非分頁記憶體池的增加。該變化不會引起任何明顯的問題。

 

參考附錄E以獲得對FastSendDatagramThreshold 鍵設定更深入的資訊。

 

注意：不正確的編輯登錄檔會嚴重損害你的系統。編輯你的登錄檔之前應該備份電腦上任何有價值的資料。

 

伺服器名稱空間設定

 

WMS在預設的情況下已經被配置中典型的情景下能夠達到最優的效能。但是，在某種條件下，你可能會被要求來改變一些名稱空間的設定來配合某些記憶體受限的情況。改變名稱空間設定的首要原因是防止伺服器耗盡記憶體地址空間，當你使用擁有大於2GB系統記憶體的高效能硬的時候，這種情況會發生。改變名稱空間設定也能夠減少點播受限系統的記憶體瓶頸。通常，每一個32位的應用程式被限制使用最多4GB記憶體——2GB分配給使用者模式記憶體，另外2GB分配給核心模式操作。當WMS程式（WMServer.exe）達到2Gb記憶體的限制，他可能將不能分配記憶體給額外的客戶連線。即使伺服器只能夠分配2GB的使用者模式記憶體，你仍應該考慮本文'系統記憶體'章節提到的一些建議。高度推薦加多記憶體給你的伺服器。因為核心可能會分配多餘的記憶體給不同的系統操作，比如檔案快取。

 

因為WMS已經被配置最優化的效能，下面的改變可能會對伺服器效能產生負面影響：

 

l         增加每秒讀操作的數量。這個值的改變可能會減少伺服器的整體效能，因為伺服器可能需要每秒大量的資料來源讀操作並且資料來源讀操作的大小可能會減少。

 

減少UDP重發快取。如果你減少這個值，伺服器保持的用來確認重發的資料也會減少。因此，通過高度等待網路由UDP連線到伺服器的客戶端可能會受很大的影響。

 

我們推薦在弄清改變對伺服器整體效能和終端使用者體驗的影響前不要對伺服器名稱空間做改變。請注意下面的設定上相關聯的，意思是說實際的內部快取的大小和每個客戶佔用記憶體的大小可能不精確的與具體的值相等。每使用者佔用記憶體的多少取決於伺服器內部引數的組合。

 

你能夠使用下面的配置設定來減少分配給每個使用者的記憶體，尤其是伺服器遇到記憶體瓶頸的時候。參考附錄B來獲取如何進行變更。

 

l         OptimalBufferSizeInMSecsOnDemand 定義最大快取大小，單位是毫秒，分配給點播發布點的每個連線。

最小設定=0X3E8(1000ms)

預設"最大設定=0X2710(10000ms)

<node

name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="HEX_VALUE_HERE"

/>

 

l         MaxBufferSizeInBytes 定義最大快取大小，單位是位元組，分配給任何釋出點的每個連線。

 

最小設定=0X200(512bytes)

預設"最大設定=0X40000(256Kbytes)

<node

name="MaxBufferSizeInBytes" opcode="create" type="int32" value="_HEX_VALUE_HERE"

/>

 

l         MaxResendBufferSizeInMSecs 定義最大快取大小，單位是毫秒，分配給UDP重發操作的每個連線。

 

最小設定=0X0（0ms）

預設"最大設定=0X2710（10000ms）

<node

name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710"/>

 

請使用下面的表作為伺服器配置的指南，尤其是當你的目標聽眾使用低速的連線（典型是使用撥號連線，速度為10Kbps到40Kbps）

 

Namespace value	Range
OptimalBufferSizeInMSecsOnDemand	0x7D0 - 0xBB8
MaxBufferSizeInBytes	0x2000 - 0x4000
MaxResendBufferSizeInMSecs	0x7D0 - 0xBB8

 

請使用下面的表作為伺服器配置的指南，尤其是當你的目標聽眾使用高速的連線（典型是使用寬頻連線，速度為100Kbps到400Kbps）

 

Namespace value	Range
OptimalBufferSizeInMSecsOnDemand	0xFA0 - 0x1F40
MaxBufferSizeInBytes	0x8000 - 0x10000
MaxResendBufferSizeInMSecs	0x1388 - 0x1B58

 

如果你的目標聽眾使用500Kbps或者更高的速率連線到伺服器，那麼則不必改變任何名稱空間配置。在這種情況下，其他的系統資源將會在伺服器遇到記憶體瓶頸問題前就耗盡。

 

 

Appendix D: Changing Namespace Buffer Settings

Caution   Before you edit the namespace, verify that you have a backup copy of the configuration file that you can restore if a problem occurs. If you edit the namespace incorrectly, you may be required to reinstall any product that uses the Windows Media Services namespace settings. Microsoft cannot guarantee that problems resulting from incorrectly editing the namespace can be solved.

Stop Windows Media Services (run the net stop wmserver command).

Change to the directory where the namespace file is located (%SystemRoot%"System32"Windows Media"Server).

Open the ServerNamespace.xml file in a text editor, such as Notepad.

Locate the Other node in the namespace.

Add the PacketPump sub-node under the Other node after any existing sub-nodes:

<node name="PacketPump" opcode="create" > ... </node> <!—PacketPump -->

Add the following values to the PacketPump sub-node to modify the default values. If you do not make any changes, the default value is used. See to the "Advanced Tuning" section of this paper for appropriate values recommendations.

<node name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="0x1f40" />

 

<node name="MaxBufferSizeInBytes" opcode="create" type="int32" value="0x10000" />

 

<node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710" />

Restart Windows Media Services (run the net start wmserver command).

The following is an example of the code that you can add to the ServerNamespace.xml file:

<node name="Other" opcode="create" >

    <node name="Client Upgrade" opcode="create" >

    ...

    </node> <!-- Client Upgrade -->

    <node name="PacketPump" opcode="create" >

        <node name="OptimalBufferSizeInMSecsOnDemand" opcode="create" type="int32" value="0x1f40" />

        <node name="MaxBufferSizeInBytes" opcode="create" type="int32" value="0x10000" />

        <node name="MaxResendBufferSizeInMSecs" opcode="create" type="int32" value="0x2710" />

    </node> <!-- PacketPump -->

</node> <!-- Other -->

 

Appendix E: Registry Keys

Caution   Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

FastSendDatagramThreshold

HKEY_LOCAL_MACHINE"System"CurrentControlSet"Services"AFD"Parameters"

FastSendDatagramThreshold. This setting controls how datagrams are sent to the client computers. Datagrams smaller than the default go through the fast I/O path or are buffered during the send process. Larger ones are stored until the datagram is actually sent. Fast I/O means that the server copies data and bypasses the I/O subsystem instead of mapping memory and going through the I/O subsystem.

Set this key to a value that is larger than the packet size of the highest bit rate stream the server will deliver.

Type: DWORD

Default: 1024

Recommended value: 1500

 

Appendix F: Performance Counters

The following performance counters were used to collect performance and scalability information during Windows Media Services tests. The sample rate was set to 1 second.

 

Processor:

"Processor(_Total)"% Processor Time

"Processor(_Total)"Interrupts/sec  

 

Windows Media Services counters:

"Windows Media Services"Current Streaming Players  

"Windows Media Services"Current Connected Players  

"Windows Media Services"Current Late Send Rate 

"Windows Media Services"Current Late Read Rate 

"Windows Media Services"Current Connection Queue Length

"Windows Media Services"Current Connection Rate

"Windows Media Services"Current File Read Rate (Kbps)  

"Windows Media Services"Current Player Allocated Bandwidth (Kbps)  

"Windows Media Services"Current Player Send Rate (Kbps)

"Windows Media Services"Current UDP Resend Requests Rate   

"Windows Media Services"Current UDP Resends Sent Rate  

 

Windows Media Services process counters:

"Process(WMServer)"% Privileged Time   

"Process(WMServer)"% Processor Time

"Process(WMServer)"% User Time 

"Process(WMServer)"Handle Count

"Process(WMServer)"Page Faults/sec 

"Process(WMServer)"Page File Bytes 

"Process(WMServer)"Private Bytes   

"Process(WMServer)"Working Set 

"Process(WMServer)"Pool Nonpaged Bytes 

"Process(WMServer)"Pool Paged Bytes

"Process(WMServer)"Virtual Bytes

 

System counters:

"System"Context Switches/sec   

 

System memory counters:

"Memory"Page Faults/sec

"Memory"Cache Bytes

"Memory"Committed Bytes

"Memory"Available Bytes

 

Physical disk counters:

"PhysicalDisk(_Total)"% Disk Time  

"PhysicalDisk(_Total)"Current Disk Queue Length

"PhysicalDisk(_Total)"Disk Bytes/sec   

"PhysicalDisk(_Total)"Disk Read Bytes/sec  

 

Network interface counters:

"Network Interface(*)"Output Queue Length  

"Network Interface(*)"Bytes Sent/sec   

"Network Interface(*)"Packets Sent/sec 

"Network Interface(*)"Bytes Received/sec   

"Network Interface(*)"Packets Received/sec 

"Network Interface(*)"Packets/sec

 

Remote file systems – NTB connections (NetBIOS over TCP/IP):

"NBT Connection(Total)"Bytes Received/sec

"NBT Connection(Total)"Bytes Sent/sec

"NBT Connection(Total)"Bytes Total/sec

 

本文PDF格式下載地址：中午簡體版本：http://files.cnblogs.com/木虛/優化Microsoft_Windows_Media_Services_9.pdf
                                    英文原版：
 http://files.cnblogs.com/木虛/Optimizing_Microsoft_Windows_Media_Services_9_EN.pdf