Tag Archives: mtr

Selecting the Best Geographical Location for your Hosting

Choosing the best geographic location for your hosting

How to choose the best  geographic location for your hosting.

Selecting the best geographical location for your hosting is as difficult as your needs are or are not.

We have a simple four-step process to help you get started in determining the right geographical location for your hosting.

1. First, you need to establish who the audience is to be served from your hosting.  Is the audience yourself? Is it local or regional businesses? Or is it something more complicated?

2. Second, you need to establish where your audience geographically is located.  Is the audience in a single state or multiple states?  Are they in a limited geographical region like say the US Northeast? Or perhaps they are are mostly in a country like France?

3. Third, you should try to determine (where you can and where dealing with a limited audience) who their upstream providers are (read: their ISP).  If your audience is small and anticipated to be focused on a limited geographical area this is doable.  If your audience is large or broad geography, then this step probably isn’t able to be accomplished.

4. Fourth, you should try to determine the network route between your hosting and your audience. Is there good local or regional peering in place, or do packets travel the long route states away.  This travel will add usually unnecessary latency.  This step is highly relative when you have local and regional audiences.

Tools to Determine Routing and Latency

Linux has several tools you should become familiar with that will help in solving network issues, viewing latency, seeing how packets travel, etc.  There are similar tools available in Windows by default.

The most common tools to become familiar with are:

ping – returns a simple time value for each packet indicating the time for packet to be sent to the remote location and acknowledgement to happen and be received by the origin location.  This is the easiest form of latency testing, but only shows a portion of the total network picture.  The lower the ping ms value the better.
(note: some networks may ignore or drop ping requests – it indicates a traffic management policy and does not mean their network is failing)

Example: ping 4.2.2.2

PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_req=1 ttl=56 time=77.3 ms
64 bytes from 4.2.2.2: icmp_req=2 ttl=56 time=83.0 ms
64 bytes from 4.2.2.2: icmp_req=3 ttl=56 time=80.7 ms
64 bytes from 4.2.2.2: icmp_req=4 ttl=56 time=81.4 ms
64 bytes from 4.2.2.2: icmp_req=5 ttl=56 time=82.5 ms
64 bytes from 4.2.2.2: icmp_req=6 ttl=56 time=89.1 ms
— 4.2.2.2 ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 77.346/82.382/89.139/3.557 ms

traceroute – shows you the hops or steps your packets are traveling from your origin server to the remote location.  This will help you to see how far your hosting is from your audience.  The fewer the hops, usually the better.

Example: traceroute 4.2.2.2

3  xe-0-0-1-3602.cr1.tor2.ca.nlayer.net (69.31.143.109)  79.876 ms te0-0-0-34.215.ccr22.yyz02.atlas.cogentco.com (38.104.251.245)  81.321 ms  80.824 ms
4  ae0-30g.cr1.tor1.ca.nlayer.net (69.31.143.24)  79.119 ms be2437.ccr21.alb02.atlas.cogentco.com (66.28.4.197)  85.997 ms  84.276 ms
5  be2106.ccr21.jfk02.atlas.cogentco.com (154.54.3.49)  87.131 ms ae2-50.tor10.ip4.gtt.net (199.229.230.89)  79.409 ms  79.704 ms
6  * as3356.tor10.ip4.gtt.net (46.33.80.42)  76.615 ms be2063.ccr21.jfk05.atlas.cogentco.com (154.54.47.58)  78.647 ms
7  4.68.62.25 (4.68.62.25)  90.480 ms * *
8  b.resolvers.Level3.net (4.2.2.2)  89.036 ms  88.008 ms  90.349 ms

mtr – is essentially a more refined traceroute that continues to make attempts, averages times, shows the high and low ranges.

Example: mtr 4.2.2.2

3. xe-0-0-1-3602.cr1.tor2.ca.nlayer.net                                   0.0%     8   70.5  87.8  70.1 146.8  27.6
4. ae0-30g.cr1.tor1.ca.nlayer.net                                         0.0%     8  130.8  86.9  66.9 149.3  33.2
5. ae2-50.tor10.ip4.gtt.net                                               0.0%     8   73.2  75.7  63.1  98.0  11.2
6. as3356.tor10.ip4.gtt.net                                              37.5%     8   79.0  86.8  72.4 128.0  23.4
7. ???
8. ???
9. ae-72-72.csw2.NewYork1.Level3.net                                      0.0%     8   98.1  87.6  81.8  98.1   6.3
10. ae-2-70.edge2.NewYork1.Level3.net                                      0.0%     8   83.1  86.1  79.9  96.8   5.6
11. b.resolvers.Level3.net                                                 0.0%     7   81.2  82.1  78.3  88.4   3.1

mtr and traceroute may not be included in your default OS installation.   In Debian, to add these simply become root and type:
apt-get install traceroute mtr-tiny

Simple Facts

The closer your servers are to your audience, will almost always  result in better performance.  The closest you can get without exotic hosting arrangements is to be on a direct peered network.  Networks are often oversold by internet providers and have undue latency.  So no two networks will perform identically even if they are on paper identical.   Latency for instance might be low (which is good) but throughput on one of the networks might be severely limited (which is bad).

Serving your customers from multiple timezones away or from opposite side of a country in a place like the United States is introducing too many unknown variables over that packet path.  Slow throughput could be on either end, it could be an overloaded network hop along the way, it could be QoS intended to shape traffic for the common good (i.e. to stretch the finite commodity of their bandwidth).

Sample Scenarios

Your audience is in New York City, New York, USA.  They use many different providers.  Your solution would be to choose a hosting plan in a facility with diverse upstreams (multiple upstreams) including peering to the popular NYIIX public peering exchange.  Ideally much of your traffic will stay local and go via the peering exchange or via other routes where there is an often common upstream provider on both ends.

Your audience is in a lesser tier city like Syracuse, New York, USA.  You should be able to focus in lower tier cities on incumbent telco providers and the franchise agreement issued cable company to address most of this audience.  Locate an IP addresses for the telco and cable franchise where such a duopoly exists.  Perform ping, traceroute and mtr tests between you hosting location and audience in Syracuse.  If you are lucky, a market like Syracuse will backhaul traffic to New York city to get out to the rest of the internet, and you can deal with a hosting provider in New York City or nearby that has multiple upstreams and NYIIX peering.  If you are pushing lots of bandwidth or latency sensitive applications like VOIP or video you may do best to host within the incumbent networks and within the actual geographic market you are serving.  This approach of dealing with incumbents and within their network often is rather expensive and limited only to very large companies (due to cost and complexity).

Your audience is in France, a country you know not so much about.  Fortunate for you, latency in Europe is noticeably lower than say in the United States.  Your testing simply would  be focused on major European peering exchange points (amsix, LINX, DE-CIX, etc.) and latency/time to major internet providers within France.  You want a provider, as always, with diverse upstreams and peering exchange transit.

Do these approaches work 100% of the time for every member of audience? No.  However, those on healthy modern networks with good routing and minimal network QoS or other introduced delays will absolutely see a noticeable increase in performance.

One other way to partially address these other audience members is through use of the third-party CDN service.  While CDNs are more advanced solution, they aren’t perfect either.  You will pay heavily for a proper CDN worth considering and implementations can be rather complex.

In future related post we’ll discuss CDNs (Content Distribution Networks), when and where to use them, and content caching, why you need to cache your content.

About tmzVPS

tmzVPS offers affordable large resource virtual hosting solutions (VPS) from three different geographic locations in the United States, and one location in the United Kingdom. We offer unmanaged VPS packages for the more technically adept, and managed VPS for those just getting started.

tmzVPS servers use RAID10 disk arrays for data redundancy, and we perform daily backups of all servers for peace of mind. Our upstreams are diverse and they have peering to major internet traffic exchanges.

Contact us today to learn how tmzVPS can help you with you choose the best geographical hosting location to serve your audience.
sales@tmzvps.com