

Global average response times from EC2 regions - rkalla
http://www.cloudconnectevent.com/2011/presentations/free/76-marty-kagan.pdf

======
veidr
It's interesting, but the granularity is kinda weird. >300ms is a nonstarter
for all kinds of web apps here in Japan.

I worked on a web app project here where we absolutely could not use EC2 APAC
(when it was only Singapore), and ping times to EC2 were 60ms. We had to put
physical boxes in a Tokyo data center. It was only when Amazon opened their
Tokyo region (8ms ping times from real users) that the customer was okay with
the speeds.

So is would have liked to see finer gradations of these results. Still cool to
have the info, though.

~~~
rkalla
Agreed, < 125ms is typically an OK range (for most things) but < 300ms is
_really_ nebulous. There are apps I would stop using fairly quickly if 300ms
was the norm.

Thanks for the tip on Tokyo data center for EC2, I've seen a lot of complaints
for the Singapore data center in general with terrible times into China and
Tokyo before and wasn't sure how the people actually in those regions felt
about the response times.

------
hopeless
That's interesting. So U.S.-East seems the best option for supporting both the
U.S. And most of Europe. Although if you're slightly less concerned about the
U.S. Then the EU seems a reasonable conpromise.

One thing I doubt is the uniform ping times within countries. For example, do
we really think ping times are uniform across the breadth of Russia?

~~~
barrkel
0-300 is a pretty wide category, though; 300ms is not a great response time.
Better would be to target 100ms. A logarithmic scale would probably have
served better in the color-coded maps.

------
cwp
Wow, wish I could have seen that talk. I recently got similar results by doing
client-side load balancing: 27% improvement, on average, for users that were
not close to EC2 East.

See
[http://instantdomainsearch.com/articles/faster_domain_name_s...](http://instantdomainsearch.com/articles/faster_domain_name_search/)
and (very brief) HN discussion: <http://news.ycombinator.com/item?id=3045333>

~~~
rkalla
For what it's worth, I liked the article and the idea of client-side real time
balancing presented in the article when you submitted it.

Something similar happened when I launched <http://hnnotify.com> \-- got 24 up
votes and then it crawled into oblivion <shrug>

------
ericHosick
With regard to their Regions.

Based on this data, you can have really fast responses around the world if you
provide your services in all regions.

However...

It is really difficult to get their cloud services to work across Regions
(AMIs not shared, security not shared, RDS, Cloud-formation only works in one
region, etc.). If you want to run in multiple regions, you need to use EIBs
for your database servers (mysql, mongo, etc.), setup your own replication and
fail over, etc.

All in all, though, a great service (though at first, I didn't like the entire
degraded server problems but realized it has forced the issue of not assuming
servers will not fail).

~~~
rkalla
> you need to use EIBs for your database servers

"EIBs"?

I would point out that global replication is one of the things that makes
CouchDB's master-master replication so tasty.

You can't accomplish the same thing with Mongo in a R/W environment since you
can only write to the master in a replica set. You could have multiple read-
only slaves in other geographical locations, but that isn't always helpful.

You can also somewhat fake it with a much more complex mongo-replica-set-per-
region sharding configuration, but then you don't have the same data available
in each region in each replica set.

PostgreSQL in 9.1 added master/master streaming replication which is nice. Not
sure what MySQL does in these situations.

~~~
zwily
Postgres' built-in streaming replication isn't master/master. That'd be nice
though. :)

~~~
rkalla
Bah, good catch. Sorry about the mis-statement. For anyone interested here are
some replication solutions for PostgreSQL that might be interesting:
[http://wiki.postgresql.org/wiki/Replication,_Clustering,_and...](http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling)

------
Havoc
That doesn't look right to me. My country (South Africa) gets ping times of
<250ms for pretty much anything international, yet the chart shows 500-750ms.
Where is the other 250-300ms coming from?

------
prakash
Here's a country based comparison of cloud perf:
[http://www.cedexis.com/which-is-the-right-cloud-for-the-
job-...](http://www.cedexis.com/which-is-the-right-cloud-for-the-job-it-
depends/)

You can get access to this data (my comment above and the cloud connect
presentation) by signing up for a free account on our site:
[http://www.cedexis.com/which-is-the-right-cloud-for-the-
job-...](http://www.cedexis.com/which-is-the-right-cloud-for-the-job-it-
depends/)

------
mixmastamyk
Enlightening, thanks. A shame that none of the big names have a data center in
South America. I've a project I'd like to bring to Brazil at some point and
300-500ms is not very good. What will it take to open up a node in Sao Paulo
or Buenos Aires? Is it lack of traffic or taxes holding up progress?

~~~
rkalla
mix, EC2 just opened a Sao Paulo EC2 data center this week or last week, so
you are good to go.

$0.25/GB though so it is a bit pricey.

~~~
shykes
Unless I'm mistaken, there is now a Cloudfront edge in Sao Paulo, but no EC2
region. This may or may not be appropriate for your project.

~~~
rkalla
Damn, shykes you are exactly right it was just an edge location and Route53
node, not an EC2 region.

Sorry about that guys.

------
oacgnol
I find it odd that GAE has lower average response times in Canada than it does
in the USA. However, as others have said, the granularity of the study leaves
a lot to be desired.

------
highriseo
Why is it that Canada is consistently getting better or equal performance than
the US? I would think that most traffic requests from Canada are routed
through the US.

------
Joakal
What are the geo static and performance load balancers?

I can only look up mixed definitions.

