4.2.1 客戶端間訊息傳遞與接收串流反應時間測試
測試目的：
當一個客戶端取得發佈權時成為新發佈端時，需要通知原發佈端接收串流，這個過 程會受到影音伺服器和訊息傳遞伺服器負載不同而有延遲時間。測試兩個伺服器在不同 人數負載情況下，通知串流接收到接收完成的延遲時間。
測試方法：
訊息傳遞路徑為：發佈端 Flash A 向訊息傳遞伺服器發送訊息，訊息內容為：“要 求客戶端向影音伺服器接收串流＂，訊息傳遞伺服器轉送訊息給接收端 Flash B，接收 端收到訊息後向影音伺服器送出接收串流的要求，取得影音串流。如圖 4-5 所示應用實 例：發佈端傳送訊息要求新加入活動的使用者接收影音串流。
圖 4-5 客戶端 Flash 程式要求其他客戶端接收影音串流的通知路徑 訊息傳遞伺服器
影音伺服器
Flash A Flash B
1.發送影音讀取通知 2.取得指令通知
3.讀取影音串流
60
61
圖 4-6 使用實機之測試結果
橫軸為影音伺服器和訊息傳遞伺服器負載的使用者人數，縱軸為各階段測試時間差。
圖 4-7 改以軟體模擬使用者之測試結果
橫軸為影音伺服器和訊息傳遞伺服器負載的使用者人數，縱軸為各階段測試時間差。
當設定的使用者人數到達 450 人時，T4-T3開始有明顯的增加，而T3-T1依舊無太 大起伏，再參考 4.1 影音伺服器的負載測試結果可得知，450 人以上已經接近影音伺服 器的滿載人數，則整個訊息傳遞流程的時間差T4-T1增加，主要是因T4-T3影音伺服器 的負載接近上限而回應遲緩影響。
本次測試得知在影音伺服器和訊息傳遞伺服器同樣服務相同人數時，會先受限影音
62
伺服器的負載能力而無法再繼續增加服務人數。
4.2.2
多人連線發佈與接收串流之效能測試
測試目的：
在一個多人視訊連線活動中，發佈端發佈串流給活動內所有成員使用者，測試所有 成員成功接收串流的延遲時間與活動內成員人數的影響。
測試方法：
一位成員使用者邀請N位其他使用者加入多人視訊連線活動。活動建立並且其他使 用者加入完成後，使用者 A 擁有發佈權成為成員發佈端，其他使用者為成員接收端。
發佈端發佈一個 400Kbps 串流到影音伺服器，同時記下時間 Tstart，各接收端成功接收串 流各自記下時間TR1、TR2、…、TRN，則最大發佈與接收的延遲時間差為Max {TRi – Tstart}， i = 1,2,…,N。
測試數據：
圖 4-8 為一次發佈串流給多位使用者時，比較發佈端和所有接收端的時間差取最大 者，越高代表該使用者越晚才會接收到串流。
圖 4-8 發佈開始到所有接收端完成接收之接收端最大延遲時間差圖 橫軸活動中成員接收端的數量，縱軸為延遲時間差（ms）
63
因硬體資源與人力限制，僅測試 20 位使用者，如圖 4-8 所示，最大延遲時間差隨 著客戶端數量增加，直到十人之後維持在一秒左右，接著最大反應時間不再有明顯成長。
此一測試結果說明發佈與接收之間或多或少會有時間差，此為 3.2.3.2 小節描述的 客戶端間同步問題的影響元素之一，時間差受到網路環境、客戶端硬體設備、伺服器處 理時間、串流本身的資料速率等許多可控制和不可控制的因素影響。本論文就針對緩衝 區使用量，盡量減少產生客戶端間同步問題的可控制因素。