+1 for having frontside cache servers in multiple regions. As long as you have reasonably cacheable content it can be a pretty substantial speed improvement.
On Wednesday, November 14, 2012 8:02:50 PM UTC+11, James Healy wrote: > > On 14 November 2012 09:52, John Dalton <[email protected] <javascript:>> > wrote: > > Having an app hosted in Sydney talking to a DB server in the USA will > > be much slower than having both servers in the USA - this is because > > your app will typically make multiple DB calls per request, so you're > > multiplying the delay rather than reducing it. > > An alternative would be to host a nginx/varnish/something proxy on EC2 > in Australia that maintains a keep alive HTTP connection to the > upstream app servers in the US. > > Users will have low latency to the local caching server, and despite > all requests still tromboning to the US and back, the response time > will be faster because the user avoids the multi-RTT TCP handshake > across the pacific. > > I guess the trick is deciding whether the speed improvements are worth > the extra complexity in the architecture. > > James > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/zR45uNGp0QMJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
