IaaS Performance Benchmarks Part 4: Google Compute EngineIaaS Performance Benchmarks Part 4: Google Compute Engine
As part of my project comparing IaaS services, I tested Google Compute Engine and also compared it to AWS. Here are the results.
This is the fourth part in a series of articles about creating my own IaaS performance benchmarking project. In the first part, I explained the methodology I'm using to test instance types across major IaaS providers. In the second and third parts, I ran benchmarks across every instance type in every US region run by Amazon Web Services (AWS), the most widely used IaaS provider. In this part, I look at Google Compute Engine (GCE), which just came out of beta and is widely seen as one of the biggest potential competitors to AWS. I compared instance types across GCE as well as against AWS.
As of today, there is only one US region with two zones available for GCE in RightScale. In that region, in each of its zones, I kicked off one of each GCE instance type that comes with local disk storage, for a total of 24 VMs. As with AWS, I ran on RightScale’s CentOS 6.4 images. One note: GCE makes life simpler than AWS in terms of pricing, as you don’t have to deal with choosing and allocating reserved instances, and GCE bills in minute increments, not hour increments. That said, because AWS is the industry leader, when I compare GCE to AWS, I will calculate both the most expensive and cheapest pricing that AWS can provide.
GCE Instance Comparisons
Here are the main takeaways that I have from comparing instance types across GCE:
• Performance is consistent across both GCE zones, regardless of instance type (except that you should expect the performance of the f1-micro to fluctuate). This is good, although with only two US zones, it’s hard to really compare GCE to AWS.
• The best price-per-performance comes with the f1-micro (which is subject to more serious fluctuations in performance; your mileage will vary at any given moment), although both the g1-small and n1-standard-1 are fairly close.
Read the rest of this article at Network Computing.
Read more about:
2013About the Author
You May Also Like