Super-Networking Blog

So this is a follow-up post to Latency Vs. Bandwidth where I gave a good link to an explanation on the differences between the problem of Latency and Bandwidth on the Internet. The same blogger had a follow-up post that explained a few ways for you to help improve high latencies.

This is another good article that goes over some of the things you can do to mitigate latency problems. I am going to go through a couple of things on this topic myself:

“Tweaking the host TCP settings” was one of his things to try and I agree that if you do it right this can help a great deal but if you tweak it wrong it can make things a whole lot worse. Be sure to test it in a lab before doing anything in production. Also another FYI on this method is that Windows Vista auto tunes your network setting so you are better off just letting it make the changes unless you have major problems.

Another method that he brings up is to move mission critical Internet web pages or downloads to a CDN network. This is a great idea but be wary of the price that this can cost you. There are a lot of them out that and some are cost effective and some are not. I did a mini review of some of the choices here.

Another thing you can do that should help is if you have an application that needs to stay in your datacenter and you need to get it cross county under a maximum latency is work with your ISP. Most of the time your traffic will switch through multiple ISPs between your datacenter and theirs if it is a long distance away. This can cause major increases in your latency.

A couple of ways to mitigate this is to possibly switch your ISP to the same ISP as the business you need to work with. If it is a lower bandwidth need you could get a point to point link, or if it needs to be a higher bandwidth connection you should look at the possibility of getting a MPLS tunnel from end to end through your ISP.

One more tip which doesn’t really relate to Latency but will help if you are wondering why your transfers are so slow over a large pipe. Use parallel transfers, if you have large amounts of data to transfer over long distances either program it in or find a programs that running multiple streams at the same time. You will find a huge increase in throughput.

There are a thousand ways to look at this but hopefully between the post from the EdgeBlog and my posts you can get a lot of options.

It is really getting interesting on the bandwidth structures available to web based companies now. Amazon’s S3 service is lowering their prices even more than before, they were cheap at $0.20/GB transfer. It is getting to the point where even with a screaming deal on an unlmited transfer plan with a capped Mbps transfer you might want to make the switch.

With some plans you can get unlimited transfer but you can say use 100Mbps at any one time for a flat monthly rate. This can seem like a good deal when you are doing a lot of constant trasfer where you aren’t going to go over the 100Mbps and are just doing a lot of data. The thing is you are capped for high traffic times and no matter if your traffic goes up, stays the same, or goes down you are getting charged the same amount. So when you are doing 90Mbps everyday it is a good deal but when you are doing 10Mbps it becomes a waste of money.

So you look at an option based on GB transfer and they will charge you monthly depending on how my transfer you do. Benefit here if your traffic goes up, hopefully are making more money, the bill goes up but if your traffic goes way down so will the bill. You aren’t tieing yourself to a flat rate you might not be using. The thing in the past was that with GB transfer costs of $1.50/GB, that you find with some CDN networks and a more average $0.50/GB, you are just coming out a lot higher on the cost than with the flat rate. Now with Amazon’s less than $0.20/GB you need to relook at your contracts. Might be time to make the switch.