在AWS的EC2進行UnixBench之測試結果

今日因應CloudTW會友之邀請，特別在AWS(Amazon雲端服務)的EC2上進行了UnixBench測試，為了客觀起見，特地開了兩個等級的EC2(m1.small、m1.large)、以及一台PC上進行測試比對。

當然，測試結果僅能做為參考，畢竟影響網路應用服務運作效能的因素有太多環節(有拿到小弟簡報內容的朋友應該就會了解)，而往往也可以因應不同瓶頸再來做不同的規劃調整，而以AWS服務來說，其讓我最心動的就是：頻寬夠大、成本低、啟用迅速方便，而且服務種類多(可交互搭配)！

至於UnixBench的測試主要是許多在使用VPS服務的朋友會先拿來測試主機效能的軟體，包括下列測試：Dhrystone、Whetstone、Execl Throughput、File Copy、Pipe Throughput、Pipe-based Context Switching、Process Creation、Shell Scripts、System Call Overhead、Graphical Test等項目(至於每個項目的測試用意在官方網站都有解說，有興趣深入的朋友可以再深入研究哦)，而在官方網站也強調UnixBench的效能測試不是針對CPU、RAM或Disk I/O，而是針對整體性的效能(但不包括網路吞吐量)，連使用的系統、Library甚至Complier都會造成效能評測的影響哦(若有想要用UnixBench進行測試的朋友，千萬別在上線中的機器進行，以免出現意外～)

廢話不多說，下面就是測試的環境和相關的測試結果，請大家享用：

直接列出測試環境和結果：

 

註：上述有*符號的是指在UnixBench測試結果所列出的CPU等級

 

EC2(m1.small)在進行測試時的CloudWatch圖表：

UnixBench的Result Score:

 

EC2(m1.lagre)在進行測試時的CloudWatch圖表：

UnixBench的Result Score:

 

XPC上的UnixBench的Result Score:

 

總結：

若單以UnixBench的測試結果來看，AWS的EC2(m1.small)確實不夠理想，也難怪有些創業家會覺得AWS的m1.small是很爛的東西，但換個角度來看，一個好的應用服務原本就要考量到所有營運的環節，包括頻寬、Client端程式、Server端程式、資料庫、系統及各種相關的技術等等，當然也包括使用者的操作流程規劃、介面設計及UE(或稱UX，使用者體驗)的考量，小弟雖然不才，但仍覺得當中有許多流程可以被設計來適當進行負載的分擔，例如在Client端程式選擇可以分擔運算能力的程式就可以有效避免把Loading都卡在Server端；又如Client端在取回資料時，是否可以僅取回最少、最有用的資料即可，不必大費周章地將所有資料都撈至Client端，如此不僅可有效減少資料封包、節省頻寬資源、還能增加使用者的正面體驗；再如許多需要用到大量運算能力的程式是否可被排在負載較空閒的時間進行? 或是善用db replication在別台進行? 甚至可以在Client端直接進行? (例如Flash/Flex的RIA應用就很適合在Client端負責繪圖的部份，後端只要傳回一包資料即可)…

小弟相信，雖然AWS的EC2(m1.small)在UnixBench測試中沒有得到很好的分數，但透過上述提到的許多方式進行整體架構的規劃(當然還有很多、很多的好技術、好方法，是小弟正在努力持續學習的)，那麼就能適當發揮AWS提供的優勢，而非其劣勢了～

 

特別補充(EBS的UnixBench測試)：

由於在「AWS雲端企業實戰聖經」這本好書的作者有特別建議使用EBS做為Instance，故特別針對AWS的EBS進行UnixBench和hdparm的測試，下面是測試的結果：

UnixBench的Result Score(分數最低):

EBS(m1.small)在進行測試時的CloudWatch圖表：

EBS(m1.small)進行hdparm測試的結果(為求客觀，故進行多次)：

EBS測試小結：

優點:
1.用EBS Boot的伺服器執行shutdown指令時不會將Instance Terminated，只是將Instance給Stop而已，因此不必擔心不小心將伺服器給關掉而造成資料全部消失之問題。
2.可以在AWS Management Console中進行EBS的Snapshot來做備份。
3.EBS Volumes可以隨意被掛載、卸載為某個目錄，十分方便應用。

缺點:
1.效能是所有AWS提供的Instance中最差的，例如同樣是m1.small的等級，用EBS boot的disk讀取速度約為80MB/sec、而用instance-store的disk讀取速度約為133MB/sec。
2.EBS的租用成本不便宜，因為需要另外再加上I/O的費用(每100萬次收$0.1美金，別以為很少，I/O的存取次數遠比想像中的要多太多倍了)，仔細精算下來絕對會讓人嚇一跳。
3.很容易忘記要在AWS Management Console去把它給Terminated掉(這樣才會停止計費)，千萬要記得，不然荷包就會大幅縮水。