Sebastian Stadil —— Scalr(云管理工具制造公司)和SVCCG(世界上***的云計算用戶組織)創始人，下面我們來了解一下他對兩個服務的測試結果。

以下為譯文：

測試的背景以及先決條件

自2007年起，Scalr就成為Amazon基礎設施服務EC2的用戶;在發現幫助AWS客戶對EC2進行彈性管理大有前途之后，它們開始著手建立EC2上的相關工具。而隨著云服務的發展，各個云服務都相應擁有了自己的用戶，Scalr自然就有了自己的跨云端管理工具。為了對服務有更好的了解，Scalr會經常對各種不同的云服務做性能測試。于是在2006年發布，對比EC2擁有相同核心服務的GCE同樣也引起了他們的興趣。

眾所周知AWS一直受限于Amazon悲劇的網絡以及磁盤性能，而Google在發布GCE的同時做出了性能提升與一致性保障的雙承諾，這樣一來Scalr就更沒有放過GCE的理由了。他們申請了早期訪問，并進行了測試。在看結果之前首先看一下測試方法的相關摘要：

測試數據相關摘要

測試基準：一天兩次的收集數據，為其4天，然后取平均值。一旦某個點出現巨大差異，會將其記錄，然后作為80%觀測數據點的間隔。

進入正題，看一下GCE與EC2的區別所在：

簡潔明了的API

首先，GCE的API是非常簡單，明確并且易于使用的。在GCE里：Google將防火墻就叫做“firewalls”，虛擬局域網就稱為“networks”，同樣核心程序則是“kernels”;對于熟悉Unix的工作者簡直就是“回到了家”一樣。

引導速度的差異

GCE虛擬機的部署和啟動達到了一個令人匪夷所思的速度(Sclar之前已使用了10個以上的云服務) —— 在輸入啟動虛擬機后，不到30秒就可以成功登入。而在AWS上，讓其達到運行狀態就要花掉30秒左右的時間，而之后你仍然需要等待一段很長的引導時間 —— 服務空閑的時候總計為120秒，繁忙的時候總時間則達到了300秒!

無疑，4-10倍的速度，展示了Google強大的工程力量。 #p# 

容量上的設置區別

在Amazon的EBS上，可以在任何時候根據需要對實例的容量進行增加和減少;而在GCE上是不可以的，至少當前不允許。這是GCE阻止用戶切換磁盤以保障最小停機時間的有效手段：為已運行服務器添加容量允許你跳過引導和配置步驟開啟一個新的節點，這在將已存MySQL奴節點提升為主節點時是有幫助的，你只需要置換存儲設備。

看完劣勢，再看GCE對比EC2的優勢。磁盤可以定義給多個實例進行只讀，這將比對象存儲更加容易使用，特別是對于那些需求本地文件系統類似WordPress和Drupal的軟件。同樣磁盤也更加的快速、穩定(在Amazon推出Provisioned IOPS之前，其I/O性能一直不是非常穩定)，詳情見下表：

兩個服務讀性能相當的前提下，GCE的寫入性能快2-4倍。

 #p# 

網絡性能對比

在這一節上，EC2可以說是完敗于GCE。首先看一下用于災難恢復或者是降低延時的跨區域的文件復制：

在兩個不同區域上復制500M文件，AWS需要242秒，而GCE只需要15秒，Google快Amazon 20倍。

其次是同區域復制：同樣是500M的文件，AWS需要86毫秒，而GCE只需要20毫秒，GCE又快了AWS 4倍。

GCE的快不僅能提升現有應用程序的性能，而且允許一些新的架構出現，而高負載備份數據庫也可能會隨之實現。而據說Amazon也在建立自己的跨區域快速網絡傳輸，不得不說這是一個很讓人期待的用例。

跨地區快照克隆支持

雖然不清楚為什么AWS會不支持這個功能，但是GAE允許用戶在多個地區使用實例的快照對實例進行克隆。這將使災難恢復和區域性的維護更容易執行。同樣這迎合了人們將他們的基礎設施部署到多個區域的思想，類似于AWS在實例故障時使用的臨時本地磁盤存儲。

***，該如何選擇?

GCE的強大性能無疑讓人向往，然而別忘了其仍處于測試版本，所以強大的性能更該歸結于Google本有的底蘊。而巨頭Amazon經過多年的發展明顯已形成一套完整的服務體系，這就意味著你可以輕松的完成大型應用程序的建立;如果不擔心被其鎖定，EC2不失為一個很好的選擇。