Welcome!

@CloudExpo Authors: Yeshim Deniz, Dana Gardner, Pat Romanski, Liz McMillan, Elizabeth White

Related Topics: @CloudExpo, Microservices Expo

@CloudExpo: Blog Feed Post

Is the Performance of All Cloud Servers the Same?

CPU or processor power is described by most vendors in terms of cores

One of the benefits of delivering Infrastructure as a Service (IaaS) through the cloud is an abstraction from the underlying hardware delivering the service.  There’s no requirement to understand what technology is being used to deliver, for example, cloud servers.  The specification of a cloud-based server is based on a few simple metrics, CPU, memory and disk space.

CPU or processor power is described by most vendors in terms of cores, which translate to some abstract definition of physical computing power.  Only Amazon Web Services (AWS) reference physical CPU architecture, with processing assigned EC2 Compute Units (ECUs).  You can find more details here, but summarizing, an ECU is approximately the power of a 1.2Ghz 2007 Intel Xeon Processor.  Memory is a more tangible quantity and simply expressed in megabytes or Gigabytes.  Storage references purely disk capacity and has no correlation to actual disk performance.

Being a “storage guy” this lack of an I/O performance metric piqued my interest, as much of my professional career in storage has involved ensuring consistent and high I/O performance.  I thought it would be interesting to look at both processing power and disk I/O performance to see how the different cloud implementations match up.

Measuring Performance
Now I could install some software tool to execute the performance tests, but it’s more interesting to think about the underlying processes that are occurring on a virtual machine, so I’ve created a couple of PERL scripts to do the analysis.  For the CPU measurement, I’ve simply created a script that loops for a fixed number of seconds, performing maths calculations and counting the number of loops that get executed in that fixed interval; in this case one second.  A single measurement isn’t an entirely accurate measure of performance so I repeat the process at one second intervals, obtaining a series of figures that can be averaged out.

For storage I/O my PERL scripts creates a 100MB file, writing a series of random 4K data blocks.  With both scripts I measure elapsed time and the user & system CPU time taken.  If the PERL script is being executed consistently, then CPU time for each metric should be similar across all cloud environments although the elapsed time will vary by the percentage of resources being allocated.

The Results
I ran tests against the following platforms: Amazon AWS, Rackspace and GoGrid, all of which were the US-based service.  I also tried to choose a consistent platform, standardizing on CentOS or RHEL (which should be identical).  Unfortunately there is no standard version of these operating systems available on each platform, so some tests are based on version 5.6, some on 6.x.

  • AWS#1: RHEL 6.1, 2ECU (burst only), 613MB, I/O performance low
  • AWS#2: RHEL 6.1, 2ECU, 7.5GB, I/O performance high
  • AWS#3: CentOS 5.6, 2ECU, 7.5GB, I/O performance high
  • Rackspace: CentOS 5.6, 4 virtual cores, 256MB, 10GB
  • GoGrid: CentOS 6.0, 0.5 CPU Core, 512MB, 25GB disk

What’s interesting is most of the CPU performance figures came out at a similar level, except for the AWS micro-instance.  This gets more power, but after about 10 seconds of continuous use starts to get throttled.  All of the instances are different in their definitions of computing resource but effectively translate to the same amount of CPU speed (remember the script runs single threaded).

For the storage, most instances ranged between 1 & 2 seconds per 100MB file.  However, the two AWS instances using Elastic Block Store (permanent data store, retained even if the instance is destroyed) have significantly worse performance, with the micro-instance being particularly bad.  One curious anomaly is that performance seemed to improve for the micro-instance in line with the way CPU was constricted.  Although the timings were rounded to the nearest second, taking the average of all the observations, the three solutions using instance storage came out at a remarkably similar time, although AWS was slightly faster (1.4s per 100MB compared to 1.7).

So what’s the point of performing these measurements?  Well firstly, it provides an additional way to do better like for like comparisons of the different offerings.  Obviously I/O performance is not part of the server profile but can vary dramatically, depending on the instance type chosen.  If, over time, servers are migrated to new technology, the relative performance level can be evaluated ensure servers remain correctly sized.

I’ll be extending the scripts to do more complex performance testing and see if I/O varies with differing block sizes and how multi-threaded CPU tasks are handled.  Plus, there’s the whole comparison of Linux versus Windows to contend with.

TSA Cloud CPU TSA Cloud IO wan_256

Read the original blog entry...

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


CloudEXPO Stories
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this data set were also collected from prior time periods. These tweets may expand the complete time period of the data.
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts. This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
Artificial intelligence, machine learning, neural networks. We're in the midst of a wave of excitement around AI such as hasn't been seen for a few decades. But those previous periods of inflated expectations led to troughs of disappointment. This time is (mostly) different. Applications of AI such as predictive analytics are already decreasing costs and improving reliability of industrial machinery. Pattern recognition can equal or exceed the ability of human experts in some domains. It's developing into an increasingly commercially important technology area. (Although it's also easy to look at wins in specific domains and generalize to an overly-optimistic view of AI writ large.) In this session, Red Hat Technology Evangelist for Emerging Technology Gordon Haff will examine the AI landscape and identify those domains and approaches that have seen genuine advance and why. He'll also ...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and cost-effective resources on AWS, coupled with the ability to deliver a minimum set of functionalities that cover the majority of needs – without configuration complexity.
Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.