Localized Load Balancing

Need to decrease the load time for users that are far from my server.

[satlas]

I recently discovered a huge difference in the load time of my website between the east coast and west coast of the USA. I have one dedicated server located on the east coast, so it makes sense that load time is fastest there. However, I never expected the load time on the west coast to be 2-4 times longer (4 seconds vs 10-20 seconds).

I need to find a solution that will deliver my website faster to users on the west coast.

My first thought was to simply get an additional server on the west coast, and set it up so that users use the server closest to their network location. But I was told that this is an extremely expensive solution, which doesn't make sense to me.

I also thought the added benefit of having a second server would be that if one breaks down, the other would pick up the slack so there is no downtime. But again, I was told that this is not how it works.

I am extremely confused now. Can someone please explain how this works and provide me with possible solutions?

Thanks!

[jtara]

(4 seconds vs 10-20 seconds).

I'd first figure out why your pages are taking 4 seconds to load on the east coast. That's awfully slow. I suspect you are loading a whole bunch of images, possibly multiple style sheets, Javascript files, etc.

IMO, 4 seconds is unacceptable.

I would also examine your server configuration. There are a number of settings that might slow-down a home page that requires downloading many files. Perhaps others can make some specific suggestions if you will mention what server you are using.

As well, you might examine your page structure itself. Can you combine multiple images into one? Delay or eliminate loading of unnecessary style sheet and Javascript files? Combine multiple style sheets and Javascript files?

I need to find a solution that will deliver my website faster to users on the west coast.

Move your server to Texas. That's my solution, as well as WebmasterWorld's.

My first thought was to simply get an additional server on the west coast, and set it up so that users use the server closest to their network location. But I was told that this is an extremely expensive solution, which doesn't make sense to me.

There's no inherent or standard mechanism for TCP traffic to be routed to the "closest server". There is for UDP, and it's called IP-Anycast.

Solutions for routing TCP traffic to the closest server typically involve a network of customized DNS servers using IP-Anycast. (DNS uses UDP - at least usually.) The DNS servers are able to determine where the closest server is with no additional overhead, and then arrange for redirection at the HTTP level - probably by passing-on information to a centralized redirection server. There are various schemes for doing this, but I think they all are going to start out with IP-Anycast-based DNS.

There's a popular inexpensive DNS provider that does use IP-Anycast, but only for DNS. They don't offer any sort of "nearest server" rerouting for TCP traffic.

It's not an easy DIY project, and for commercial service, as far as I know, you're stuck with very costly service providers such as Akamai.

Alternately, your site could do some various kinds of sniffing, perhaps timing access to both of your sites, and then redirect the user to the closest server. But of course doing so is going to eat-up valuable time during initial page load. That's why a solution that bootstraps from IP-Anycast really is optimal.

Other schemes (or schemes used in combination with the above) might involve IP-based geolocation (inaccurate, though), and guesses based on round-trip time. (Example, 100mSec round-trip, probably west coast or Europe. But geolocates to U.S., so must be west coast.)

I also thought the added benefit of having a second server would be that if one breaks down, the other would pick up the slack so there is no downtime. But again, I was told that this is not how it works.

Now *that* part is relatively easy to do, using a third-party DNS provider. Most have a monitoring/backup service that will monitor your website, and switch DNS entries in case a site goes down.

But I'd go back to the solutions I've suggested in the first few paragraphs above. It's not commonly necessary to host in multiple locations within the U.S. to get acceptable load times on both coasts. A second server, or even moving to the middle of the country, is just going to mask the real problem.

[plumsauce]

I mostly agree with jtara, with a few minor niggles.

Ignoring whether it is dialup or not,(where 4 seconds might be phenomonal), you need to know if you are comparing apples to apples in terms of the endpoint clients you have been testing with.

Everything else being equal, midwest location might be a solution. St. Louis,MO specifically points out that they are at the geographical center of the US.

The solution I am working with contains both custom dns servers and custom reverse proxies. No anycast though. Nothing is off the shelf.

Now, you might have actually hit on a viable solution without knowing it.

What I mean is:

You *could* have a link on your pages saying "do you want to use the west coast server?". If a user clicks on it, then move him over to westcoast.example.com which is your server on the west coast. No naming conflict at all.

El cheapo, and requires your user to make a choice, but it will work without additional cost.

[satlas]

Sorry about the delay in responding, I have been very busy trying to fix this problem and your response helped a lot.

I suspect you are loading a whole bunch of images, possibly multiple style sheets, Javascript files, etc.

You are right about the excess files that are being loaded... I had a lot of old javascripts loading that were no longer necessary.

Move your server to Texas. That's my solution, as well as WebmasterWorld's.

I use superb.net for hosting, which unfortunately only has east and west coast servers. Since they have been good to me, I decided to upgrade to a much faster east coast server. Hopefully a faster server with cleaner code should alleviate the loading issues.

There's no inherent or standard mechanism for TCP traffic to be routed to the "closest server". There is for UDP, and it's called IP-Anycast.

IP-Anycast seems like a good solution if this doesn't work... but since I do not know the difference between UDP and TCP traffic, I am not sure how effective it would be. Can you elaborate?

Now *that* part is relatively easy to do, using a third-party DNS provider. Most have a monitoring/backup service that will monitor your website, and switch DNS entries in case a site goes down.

What exactly is a third party DNS provider? Can you suggest any?

I have been looking into services that monitor the website for downtime and the price range is considerable. Any thoughts on the following services?:

gomez.com
webmetrics.com
basicstate.com
mon.itor.us
alertra.com
alertsite.com
watchmouse.com

Thanks again for your in-depth response. It really helped me sort out the issues with my server :)