jread

On this topic, today HP Cloud opened access to their Akamai Anycast DNS service with 75 edge locations. Pricing is about the same as Route 53 ($0.35/domain + $0.55/million queries). Not as easy to use as Route 53 yet - configuration is via API only.

https://www.hpcloud.com/products/DNS

At the bottom of the post - ycombinator.com switched from easyDNS to CloudFlare during the past 30 days

Rackspace Cloud has regions in the US and UK only. AWS has regions globally including 3 in the US , 1 in Europe, 2 in Asia, 1 in Australia and 1 in South America. Object storage content is often sensitive in nature and not distributed publicly by CDN. Additionally, AWS provides a larger and more comprehensive suite of complementary cloud services including a more robust compute platform.

This report is essentially a summary of network connectivity between 3 arbitrarily chosen external client VMs and 5 object storage platforms: AWS S3, Azure Blob storage, HP Object storage and Google developer storage. The results are highly dependent on network proximity between said clients and provider networks. With such a small client test population and no details provided about them (other than that they are on the east coast), I think the findings are inconclusive at best, and cetainly undeserving of these kinds of sensational headlines. Nansuni even acknowledges that the most optimal test conditions for object storage is use of clients within a provider's associated compute platform.

Not really - DNS failover is typically much slower to respond compared to load balancing because records are cached.

DNS failover is subject to DNS caching and TTL. Load balancing is real time. A DNS driven failover may take 1-10 minutes to trigger versus instantaneous for load balancing. Good approach to failover is a combination of both.

Correct - it is based on the IP anycast endpoint a resolver connects to, not the geo data associated with the resolver's IP.

It is very basic - anycast endpoints in US and UK only, and no extra features like failover or geographic load balancing.

Route 53 is becoming a viable alternative to enterprise providers UltraDNS and Dyn. Performance is solid, but features have been lacking. This is a popular feature those providers charge $100+/mo for versus $0.75/mo on Route 53. Monitoring capabilities are limited (tcp and basic http only), but for many this is probably sufficient. DNSSEC is another feature I hope they will support in the future.

A few months back I wrote a blog post on the topic of managed DNS provider comparisons (performance, market share, price, features, network size, etc.):

http://blog.cloudharmony.com/2012/08/comparison-and-analysis...

I've spent the past year using Mosh from high latency, unreliable satellite connections in Afghanistan. I would have been pulling my hair out without it. My only complaint is the scrollback buffer often gets jumbled.

Low latency with a handful of pingdom monitoring nodes sitting in data centers does not necessarily translate to the "fastest repo on the web". We've tested CloudFlare since their launch using thousands of real users, and based on that testing performance tends to be on the low end compared to traditional static content CDNs. CloudFlare is more of a website proxy than CDN. By assuming full control of your website DNS, it stands out more with add-on features like security. Here is a link to some real user performance analysis I've compiled for various CDNs including CloudFlare: http://dl.dropbox.com/u/20765204/feb12-cdn-report/index.html

Just received this email, hasn't been posted to their website yet.

US military unclassified systems are a mess... a spaghetti bowl of disjoint networks, operating systems, hardware, desktop and Internet applications designed by a multitude of lowest bid government contractors with little sense for usability and often very poor technical skills.

As an aviator in the US military, I'm not surprised. This is common practice. The system in question is for public domain UK aviation charts and pubs. Many of the unclassified systems I use have the user and password taped to the monitor.

> You're not the only one to bring this up and it confuses me why. The gas infrastructure has already been built. It's a sunk cost. EV infrastructure most certainly is not.

EV infrastructure, unlike gasoline, can be piggy backed onto existing facilities - service stations, restaurants, hotels... It is much simpler to deploy and maintain - no tanks to install, no gas to deliver, no hazmat, etc. - just a connection to existing electrical infrastructure at those facilites. Adding EV charging to existing businesses also has potential to increase sales as drivers shop, eat and purchase goods etc during the wait. As EV marketshare increases, this will provide motivation to existing businesses to add EV charging capabilities on their own dime and thus stimulate the build out of such infrastructure. Tesla has finally built a practical EV that people want, which can kick start this whole process.

I’ve been working on some similar analysis with EC2 and other providers. I think the big missing point in this post (acknowledged by the author) is with regards to EBS optimized instances and provisioned IOPS where we’ve observed a dramatic improvement in IO consistency. Another interesting observation I've experienced is that performance consistency often declines using multi-EBS volume raid, likely due to variations in spindle tenancy or network latency variations. EBS test volumes were 300GB. Better performance/consistency is possible using larger EBS volume sizes.

Here are links to a couple summaries of the analysis I’ve done on EC2, Rackspace and HP. I plan on writing a blog post regarding this analysis soon.

Disk Performance: The value columns is a percentage relative to a baremetal baseline 15k SAS drive, where 100% signifies comparable performance. Benchmarks included in this measurement are fio (4k random read/write/rw; 1m sequential read/write/rw), fio – Intel IOMeter pattern, CompileBench, Postmark, TioBench and AIO stress:

http://dl.dropbox.com/u/20765204/1012-disk-io-analysis/disk-...

Disk IO Consistency: The value column is a percentage relative to the same baseline. A value less than 100 represents better IO consistency than the baseline. The value is calculated by running multiple tests on an instance, measuring the standard deviation of IOPS between tests, and comparing those standard deviations to the baseline. Testing was conducted over a period of a month on multiple instances in different AZs.

http://dl.dropbox.com/u/20765204/1012-disk-io-analysis/disk-...

You have to careful comparing one specific EC2 instance with other providers. Unlike most compute services, EC2 infrastructure is heterogenous. The c1.xlarge instance compared might deploy to 2 or 3 different chipsets in us-east-1, each with different performance characteristics. Based on the results they posted, this instance appears to have deployed to a 2.13GHz E5506 host. Most likely, Brightbox is using a homogenous infrastructure, and likely something a bit faster, like X55, X56 or E5s. For a more apples to apples comparison, they might have tested against an m2.4xlarge (8 cores) or cc1.4xlarge (8 cores hyperthreaded to 16), which are also 8 cores and deploy to X5550, X5570 or E5-2665. Based on my own benchmarking either of these instances would have performed comparably or better than the Brightbox 8GB instance.

The point is, you have a lot of options with EC2 in terms of performance, and comparing a single instance deployment doesn't really do it justice.

[Edit] Here are a few links to Phoronix results for EC2 instance types not included in their testing. m2s, cc1s and cc2s are the better CPU performers in EC2 due to faster processors. If you do a CPU performance comparison, these instance types should not be excluded (as I observe they often are):

m2.4xlarge - 8 cores - X5550 http://openbenchmarking.org/result/1208019-SU-CLOUDHARM39

m2.4xlarge - 8 cores - E5-2665 http://openbenchmarking.org/result/1208139-SU-CLOUDHARM43

cc1.4xlarge - 8 cores/16 HT - X5570 http://openbenchmarking.org/result/1208127-SU-CLOUDHARM93

c1.xlarge - 8 cores - E5506 http://openbenchmarking.org/result/1208134-SU-CLOUDHARM15

These instances were tested using CentOS 6, which will be a bit slower than Ubuntu 12.04.

This isn't unusual, amazon.com uses a combination of UltraDNS and Dyn, not their own AWS Route53 DNS service.

It won't generally affect the real user test results because of a warmup/training phase in the test when those DNS records would be cached within the recursive chain.

For direct synthetic tests we do see about 50ms response times in the US. For real user (recursive) tests we see lookups in the low 100ms range.

I created this DNS test. If your are evaluating DNS services, you might also check out a blog post I wrote last month summarizing the results we've collected from the DNS tests: http://blog.cloudharmony.com/2012/08/comparison-and-analysis...

I recently did some DNS performance analysis and wrote a blog post about managed DNS services (along with a free report):

http://blog.cloudharmony.com/2012/08/comparison-and-analysis...

Route53 is a good choice for DNS compared to GoDaddy. It has better DDOS mitigation including custom DNS hostnames across different TLDs for each zone, and zone segmenting across their network.

Yes this is true on 64 but m1s. EBS IO is still very slow and m1s generally deploy to slower Intel 53xx and 54xx hardware (although this is still often faster than the AMD 2374 you'll get on Rackspace)

> That's not quite right. The smaller rackspace instances tend to perform better than the smaller EC2 instances (anything below m1.large), especially in terms of I/O.

This is true, I mentioned this as a pro in the quota post. However, the performance is relatively flat - it doesn't scale on higher instances. On the lower end Linode tends to perform better than rackspace cloud.

Linode is a much better choice for VPS. Rackspace cloud currently runs entirely on old AMD 2374 hardware. Sure you get 4 burstable cores for all instance types, but these do not perform even close to as well as 4 core on Intel 55xx or 56xx hardware many other cloud providers utilize. Disk IO may be better with Rackspace on th low end (e.g. Compared to M1.small), but it doesn't scale, and you'll be getting the same IO on a 16GB instance, which doesn't even come close to an m2 or cc instance with EC2.

I wrote about this topic on Quora a while back: http://www.quora.com/How-does-Amazon-EC2-compare-with-Racksp...

Most of the pros and cons listed there still apply. In it's current form, Rackspace Cloud compute is little more than VPS with a few cloud features. However, the next gen Rackspace cloud platform will make significant improvements: http://www.rackspace.com/cloud/nextgen/

For now, EC2 is a far superior compute platform in just about every way.

A linode instance is included towards the bottom of the results.

We co-locate with their parent company Liquid Web and have conducted extensive testing of their cloud services. They are a very solid service, knowledgable technical staff, very quick support response, great hardware, excellent reliability, and reasonable prices. We've been monitoring Storm for 2 years with 100% availability in 2 of their 3 regions: http://cloudharmony.com/status

If you are running additional queries and need a web service token (the site currently only allows you to generate 5 reports/day for free), ping me and I'll send you one for free.

Here is a CPU performance comparison for the same set of servers. This metric is an approximation of EC2's ECU for other providers (the algorithm uses 16 CPU benchmarks and EC2 instance performance as a baseline): http://cloudharmony.com/benchmarks?benchmarkId=ccu&selec...