實驗結果

在虛擬機異質性的實驗中，我們使用一台 master(medium 型態)加上七 台 worker (1 台 xlarge、4 台 large、2 台 medium 共 7 台)組成虛擬叢集系統，

其規格如表 4-4 和表 4-5 所示，而效能評估使用三種不同的應用程式 WordCount、K-means 和 PageRank，測量其執行時間以及 throughput 的變 化，由實驗結果來分析 IMS 演算法與原先 Spark 排程演算法之效能改善。

第一個測試程式為 WordCount 程式，WordCount 是將輸入的文字檔中 的字數經過計算以後，輸出每個字出現過幾次的結果，WordCount 為 CPU-Intensive 型態的應用程式，我們將 WordCount 程式修改為兩個輸入檔 案計算完字數後，再進行 join，最後得到結果，其測試的參數分別為 2 個 partitions 數為 2，每個 partition 最大可為 128MB，在總檔案大小不變且較 少 partitions 的情形底下，IMS 演算法有明顯的提升效能。由表 4-6 可觀察 出在 5 個 partitions 的情形下，使用 IMS 演算法的執行時間較短，圖 4-11 為兩種演算法輸入 512MB 檔案在不同 partitions 的情形下執行 WordCount 所用核心數，由圖 4-12 可知，IMS 演算法在 5 和 10 個 partitions 的情形下 執行 WordCount 能夠節省 2 個 cores，故證實 IMS 演算法不僅能提升即時 串流處理效能，還能節省運算資源。

52

表 4-6 512MB 文字檔切割成 5、10 和 15 個 partitions 的執行時間 512MB 文字

檔執行順序

5 partitions 10 partitions 15 partitions Original IMS Original IMS Original IMS

20 partitions 25 partitions Original IMS Original IMS

53

圖 4-11 WordCount 執行 512MB 檔案所需核心數差異

表 4-8 和表 4-9 為 1GB 文字檔切割成 10、20、30、40 和 50 個 partitions，

使用原先 Spark 排程演算法和 IMS 演算法的執行時間比較，partitions 皆設 定為執行五次。由表 4-8 和表 4-9 可得知使用 IMS 演算法的執行時間大部 分都比原本 Spark 排程演算法來的短，並且在 10 個 partitions 的情況下效 能改善最明顯，執行時間大約縮短百分之二十，整體平均下來 IMS 演算法 的執行時間大約縮短百分之五。

54

表 4-8 1GB 文字檔切割成 10、20 和 30 個 partitions 的執行時間 1GB 文字檔

執行順序

10 partitions 20 partitions 30 partitions Original IMS Original IMS Original IMS

40 partitions 50 partitions Original IMS Original IMS 20 個 partitions 的情況下，改善效能的比率最顯著，執行時間大約縮短百

55

分之十八，而整體平均的執行時間縮短約百分之十。

表 4-10 2GB 文字檔切割成 20、30 和 40 個 partitions 的執行時間 2GB 文字檔

執行順序

20 partitions 30 partitions 40 partitions Original IMS Original IMS Original IMS

50 partitions 60 partitions Original IMS Original IMS

56

的執行時間，就能得出如圖 4-12 所示的效能改善散佈圖，由圖可知在分割 數較小的情況下，IMS 演算法對於效能改進的幅度也就越顯著，原因在於 分割數較小代表 Task 數也較少，而 IMS 演算法將 Task 集中放置在能執行 較多 Task 的機器上執行，使得 Task 彼此之間的 communication time 縮短，

進而達到較顯著的效能改善，且原本 Spark partitions 的預設分割值為 2，

每個 partitions 最大可達 128MB，故 partitions 的數目在一般的執行環境下 並不會太多，本篇論文的實驗環境最大一次可同時執行 28 個 Task，當全 部的核心數都排滿 Task 後，由於 IMS 演算法會優先挑選時脈最高的機器 優先執行，故效能還是比原先 Spark 的演算法好。由這一系列的實驗可觀 察出 Task 的數量遠大於核心數時，執行工作的 CPU 時脈高低的影響就會 顯示出來，這也就是為何在系統滿載 Task 的情形下，IMS 演算法比原本 Spark 的排程演算法效能更好。若在分割數不大於整個叢集系統的核心數 目下，平均執行時間大約比原本的還要縮短約百分之十五，分割數日趨增 加後，逼近一次能處理的最大負載量 28 個 partitions 的情況下，執行時間 平均大約比原本 Spark 的排程機制縮短百分之八，達到最大負荷量以後，

執行時間平均大約比原本 Spark 的排程機制縮短百分之四。

57

圖 4-12 WordCount 之效能改善幅度

第二種測試程式為 K-means，分別輸入 256MB、512MB 和 1GB 的檔 案切割成不同數量的 partitions 執行 K-means 程式，K-means 是先將資料分 為 x 個群組，其中每一個群組必須至少包含一項資料，而任何一個資料都 應該屬於某一個群組，依照資料之間的距離，取得群組的中心位置，切割 出群集與群集之間的界線，故本篇論文將分類參數設為 3，K-means 為 CPU-Intensive 型態的應用程式，表 4-12 和表 4-13 顯示將 256MB 的檔案分 割為 3、6、9、12 和 15 個 partitions 的執行時間，各種 partitions 的情形都 分別執行五次，由表 4-12 可知，改變測試程式後，IMS 演算法依舊在較小 partitions 的情況下，有較顯著的效能改進，隨著 partitions 數量的增加，代 表 全 部 機 器 核 心 數 的 使 用 比 率 會 越 來 越 接 近 滿 載 ， 使 得 機 器 之 間 的 communication time 大幅度增加，導致 IMS 演算法改善效能的幅度較不明 顯。圖 4-13 為兩種演算法輸入 256MB 檔案在不同 partitions 的情形下執行

58

K-means 所用核心數，由圖 4-13 可知，IMS 演算法在五種不同的 partitions 情形下皆能節省執行所需 core 數。

表 4-12 256MB 檔案切割成 3、6 和 9 個 partitions 的執行時間 256MB 檔案

執行順序

3 partitions 6 partitions 9 partitions Original IMS Original IMS Original IMS

12 partitions 15 partitions Original IMS Original IMS

59

圖 4-13 K-means 執行 256MB 檔案所需核心數差異

表 4-14 和表 4-15 表示 512MB 的檔案分割為 12、15、18、21 和 24 個 partitions 的執行時間，各種 partitions 的設定都分別都執行五次，可看出執 行時間是上下波動的情形，雖然檔案變大，但是 IMS 演算法還是能在較少 partitions 的情形下，獲得較佳的效能表現以及整體的執行時間 IMS 演算法 還是比原先的 Spark 演算法來的短。

表 4-14 512MB 檔案切割成 12、15 和 18 個 partitions 的執行時間 512MB 檔案

執行順序

12 partitions 15 partitions 18 partitions Original IMS Original IMS Original IMS 第 1 次 180.5 s 102.4 s 167.2 s 104.7 s 167.0 s 130.7 s 第 2 次 167.5 s 119.9 s 165.0 s 96.0 s 165.3 s 120.5 s 第 3 次 172.8 s 103.4 s 172.0 s 95.7 s 181.1 s 124.9 s 第 4 次 176.8 s 100.7 s 168.3 s 96.9 s 172.1 s 159.4 s 第 5 次 167.7 s 102.4 s 166.7 s 106.7 s 164.7 s 126.9 s

60

表 4-15 512MB 檔案切割成 21 和 24 個 partitions 的執行時間 512MB 檔案

執行順序

21 partitions 24 partitions Original IMS Original IMS partitions 的執行時間，各種 partitions 的設定都分別都執行五次，雖然測試 的檔案量加倍變大，整體的執行時間微幅上升，但是和原本 Spark 演算法

15 partitions 18 partitions 21 partitions Original IMS Original IMS Original IMS

61

表 4-17 1GB 檔案切割成 24 和 27 個 partitions 的執行時間 1GB 檔案

執行順序

24 partitions 27 partitions Original IMS Original IMS

使得 Task 彼此之間的 communication time 縮短，進而達到較顯著的效能改 善，且原本 Spark partitions 的預設分割值為 2，每個 partitions 最大可達 128MB，故 partitions 的數目在一般的執行環境下並不會太多，若在分割數 不大於整個叢集系統的核心數目下，平均執行時間大約比原本的還要縮短 約百分之二十，分割數日趨增加後，逼近一次能處理的最大負載量 28 個 partitions 的情況下，執行時間平均大約比原本 Spark 的排程機制縮短百分 之十五。

62

圖 4-14 K-means 之效能改善幅度

第三種測試程式為 PageRank，分別輸入 256MB、512MB 和 1GB 的檔 案切割成不同數量的 partitions 執行 PageRank 程式，PageRank 是根據網站 的外部連結與內部連結的數量和品質來衡量網站的價值，其運算概念是每 個頁面的連結都是對該頁面的一次投票，被連結的次數越多就代表被其他 網站投票越多，故能得知網路的熱門程度，PageRank 為 Hybrid 類型的應 用程式，皆具 CPU-Intensive 和 I/O-Intensive 的特性，本篇論文將 PageRank 程式的 iteration 參數統一設為 10，表 4-18 和表 4-19 顯示將 256MB 的檔案 分割為 5、10、15、20 和 25 個 partitions 的執行時間，各種 partitions 之設 定分別都執行五次，由表 4-18 得知，轉換到第三種測試程式後，IMS 演算 法的趨勢是在較小 partitions 的情況下，有較顯著的效能改進，且 Spark 的 預設 partitions 值是 2，單個 partitions 最大可達 128MB，故一般執行 Spark 的狀況下並不會產生太多的 partitions，故 IMS 演算法比原先的排程演算法 有更多效能方面之優勢。隨著 partitions 數量的增加，代表機器執行的 Task

63

數量越來越多，實驗環境的總核心數為 28，不論使用何種排程機制，Task 最後都會分配到每個核心上執行，故在分割成 25 個 partitions 的設定下，

幾 乎 已 將 整 體 的 核 心 數 都 排 滿 Task ， 導 致 全 部 Task 彼 此 之 間 的 communication time 變大，故 IMS 演算法改善效能的幅度會下滑，IMS 演 算法只比原先 Spark 演算法縮短百分之三左右的執行時間。

表 4-18 256MB 檔案切割成 5、10 和 15 個 partitions 的執行時間 256MB 檔案

執行順序

5 partitions 10 partitions 15 partitions Original IMS Original IMS Original IMS

20 partitions 25 partitions Original IMS Original IMS

64

圖 4-15 PageRank 執行 256MB 檔案所需核心數差異

圖 4-15 為兩種演算法輸入 256MB 檔案在不同 partitions 的情形下執行 PageRank 所用核心數，由圖 4-15 可知，IMS 演算法在 5、10、15 和 20 個 partitions 都能節省執行所需 core 數，故三種不同測試程式實驗所呈現的核 心數使用圖證明 IMS 演算法能節省運算資源。表 4-20 和表 4-21 顯示將 512MB 的檔案分割為 10、20、30、40 和 50 個 partitions 執行 PageRank 的 時間，各種 partitions 的設定都分別都執行五次，因為實驗環境的總核心數 為 28 顆核心，故 partitions 的數目超過 30 個以後，整個即時串流系統是處 於工作滿載的狀態，因此兩種不同演算法的執行時間差距不大，原因在於 當虛擬機都處在工作滿載的情況下，IMS 演算法的優勢只在於將 Task 放置 在 CPU 時脈較高的機器上執行，又因實驗環境中的實體機 CPU 時脈差別 不大，因此 IMS 演算法比原本 Spark 排程演算法的效能改進效果並不顯 著。

65

表 4-20 512MB 檔案切割成 10、20 和 30 個 partitions 的執行時間 512MB 檔案

執行順序

10 partitions 20 partitions 30 partitions Original IMS Original IMS Original IMS

40 partitions 50 partitions Original IMS Original IMS partitions 執行 PageRank 的時間，各種 partitions 的設定分別都執行五次，

由表 4-22 和表 4-23 可知，在尚未滿載工作量的 20 個 partitions 的情況下，

IMS 演算法依舊是有較為顯著的效能改善，達到滿載工作量以後，IMS 演 算法縮短整體執行時間的效益在百分之三到五。

66

表 4-22 1GB 檔案切割成 20、30 和 40 個 partitions 的執行時間 1GB 檔案

執行順序

20 partitions 30 partitions 40 partitions Original IMS Original IMS Original IMS

50 partitions 60 partitions Original IMS Original IMS 能執行較多 Task 的機器上執行，使得 Task 彼此之間的 communication time

67

縮短，進而達到效能改善的目標，且原本 Spark partitions 的預設分割值為 2，每個 partitions 最大可達 128MB，故 partitions 的數目在一般的執行環境 下不會太多，若在分割數不大於整個叢集系統的核心數目下，平均執行時 間大約比原本的還要縮短約百分之四十，分割數日趨增加後，逼近一次能 處理的最大負載量 28 個 partitions 的情況下，執行時間平均大約比原本 Spark 的排程機制縮短百分之十五，達到最大負荷量以後，執行時間平均 大約比原本 park 的排程機制縮短百分之三。

最後由圖 4-11、圖 4-13 和圖 4-15 可知使用 IMS 演算法執行不同的測

最後由圖 4-11、圖 4-13 和圖 4-15 可知使用 IMS 演算法執行不同的測