Global average response times from EC2 regions
11–20 of 25 posts
Re: Global average response times from EC2 regions
#12Based 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).
Re: Global average response times from EC2 regions
#13That'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?
Re: Global average response times from EC2 regions
#14With 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,…
"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.
Re: Global average response times from EC2 regions
#15With 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,…
> 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…
Re: Global average response times from EC2 regions
#16Earlier quoted context omitted.
> 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…
Postgres' built-in streaming replication isn't master/master. That'd be nice though. :)
Re: Global average response times from EC2 regions
#17Re: Global average response times from EC2 regions
#18Re: Global average response times from EC2 regions
#19Wow, 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... and (very brief) HN discussion: http://news.ycombinator.com/item?id=3045333