[NCLUG] [lug] Comparing Clouds; A trivial test.

[Quentin Hartman]

Interesting, but not surprising. What instance type did you use on AWS?
Based on what you said, and the performance you got, I'm guessing a
t1.micro? If that's the case, it's probably not a real good comparison. AWS
uses those instances to "fill in the cracks" on their host machines so they
can get the absolute maximum density. From AWS instance type docs:

"Micro instances are a very low-cost instance option, providing a small
amount of CPU resources. Micro instances may opportunistically increase CPU
capacity in short bursts when additional cycles are available. They are
well suited for lower throughput applications and websites that require
additional compute cycles periodically, but are not appropriate for
applications that require sustained CPU performance."

More info:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts_micro_instances.html

Even just moving up to a m1.small should yield substantially better results.

QH


On Fri, Oct 25, 2013 at 11:02 PM, Maxwell Spangler <
maxlists at maxwellspangler.com> wrote:

> **
> I spent some time working with Amazon, Rackspace and Google Compute Engine
> clouds this week in order to port a little Linux script I'm working on.
>
> I decided to do a simple, somewhat trivial experiment to compare cloud
> quality on a very low-end.  I wanted to learn how each cloud would handle
> the smallest of activities.  Let me stress that large, sophisticated cloud
> applications may see very different results.
>
> So I wrote a simple program in C to do several billion simple addition
> computations.  No storage, no networking, no systems calls.  This is all
> about how much time my cloud's virtual machine gets to do its job.
>
> Control:  Debian 7.2 virtual machine in KVM virtual machine on my local
> workstation.  The workstation is a 2010-era 4-core AMD Phenom II CPU with
> 12G of RAM and no other significant workloads.
>
> root at debian72:~# time ./cputest
> real 134m15.134s   [2.23 hours]
> user 134m9.707s
> sys 0m0.020s
> ------------------------------
>
> First test: Rackspace.  Unknown server with AMD Opteron 2.1GHz 4170 HE
> "Lisbon" processor.  Similar to a 6-core version of my Phenom II.
>
> [root at rackfree ~]# time ./cputest
> real 192m41.034s  [3.20 hours]
> user 192m8.815s
> sys 0m2.852s
>
> Not bad! Let's assume I'm on a shared machine with other VMs competing for
> time and therefore cluttering up the CPU caches, causing context switches
> and the hypervisor is taking IRQ activity for other system network and IO
> calls.
>
> ------------------------------
>
> Second test: Amazon AWS.  Unknown server with Intel Sandy Bridge E5-2650
> CPU @ 2.0 Ghz.
>
> 89501.70user 6.95system *24:55:26elapsed* 99%CPU (0avgtext+0avgdata
> 1440maxresident)k
> 0inputs+0outputs (0major+124minor)pagefaults 0swaps
>
> OUCH!  The first time I attempted this, it hadn't finished nearly a day
> later and my connection got dropped.  So I ran it again using 'nohup' and
> caught the output.
>
> The classic Unix 'sar' utility catches what's going on.  I hadn't seen the
> "%steal" column before, but this was a perfect case where you'd want to
> monitor it.  From the man page:
>
>  *%steal *Percentage of time spent in involuntary wait by the virtual CPU
> or CPUs while the hypervisor was servicing another virtual processor."
>
>
> Linux 3.4.62-53.42.amzn1.x86_64 (ip-999-999-999-999) 	10/24/2013 	_x86_64_(1 CPU)
>
> 09:52:58 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
> 09:53:58 PM     all     11.58      0.00      0.01      0.00     88.40      0.00
> 09:54:58 PM     all     24.46      0.00      0.03      0.00     75.51      0.00
> 09:55:58 PM     all      7.62      0.00      0.00      0.00     92.38      0.00
> 09:56:58 PM     all     13.71      0.00      0.00      0.00     86.29      0.00
> 09:57:58 PM     all     12.00      0.00      0.02      0.00     87.99      0.00
>
> ------------------------------
>
>
> This is exploratory testing of using a cloud for small workloads, not
> rigorous scientific testing.
>
> However, it's a simple and easy way to make observations about using a
> cloud resource instead of something you control:
>
> * Some cloud resources will definitely be over-committed and your
> performance will vary greatly.
>
> * Two similar virtual machine sizes on two different cloud providers may
> provide vastly different results.
>
> I hope you enjoyed this.  I did!
>
> Cheers,
>
>   --
> Maxwell Spangler
> ========================================================================
> Linux System Administration / Virtualization / Development / Computing
> Services
> Photography / Graphics Design / Writing
> Fort Collins, Colorado
> http://www.maxwellspangler.com
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>