I’ve seen so many adverts lately online for various hosting packages and co-locaton offers, data centre and so on, each one of them claiming to be the best there is thus raising the question: which one is the best really? While beauty is always in the eye of the beholder, the answer is always relative to the requirements and even more it is influenced by a multitude of factors. Therefore I’m not even gonna attempt to answer this question, but instead signal a certain aspect that gets left out a lot of times: connection rate.

You have become accustomed I’m sure with the various hosting packages ranging from “bronze” to “platinum” or from “small business package” to “enterprise” – the high end of the offers always boasting a lot of disk space and huge bandwidth. As you probably gathered from some of my previous blog entries, this is something that I am interested in and as such I’m only going to concentrate on the bandwidth aspect.

An average “top end” hosting package would probably offer you 100 Mbps or even in some cases up to 1Gbps. For your average website, assuming a page size around 10kb with 3 images averaging 40kb and a stylesheet worth about 10kb (so a total size of around 140-150 kb) this means around 100 * 1,024 / (150 * 8)= approx 85 page views per second. This is probably acceptable for most sites, even more so as figures are approximate and based on 100 Mbps lines. So for your average site their bandwidth requirements are covered and the servers are ticking along nicely.

What if your servers are not serving “simple” web pages though, what if you are a service provider? (eg ads, visitor tracking etc) You will most likely have lots of requests per second but probably hardly serve that much “content” for each request. For instance if your business is tracking user behaviour online you would base a lot of that on tagging various sites with the standard 1X1 transparent pixel and base a lot of your tracking on cookies. As such your standard reply to each request is probably around 1kb (probably even less than that but I’m being generous 😉 ). On a 100Mbps link this means you could serve in theory 100*1024/8 = 12,500 requests per second! I’m gonna approximate that to 10,000 requests per second just in case my 1kb per request was not that accurate. Now first of all if you’re thinking of taking that much traffic I’m guessing you got the servers to support it – you cannot take this traffic on one single server; to process 10,000 requests per second it means that you are taking 0.1 msec per request and your server has enough cores to sustain around 100-200 true concurrent threads… Possible, but unlikely for most of us running our software on clustered commodity hardware. Anyway to get to the point : whether you’ve got some giant machine or a cluster than can process 10,000 requests a second, how does your firewall cope?

Don’t be surprised to have everything ready in terms of application architecture and implementation, server hardware and security only to find out that the firewall provided by your ISP only copes with “normal” traffic (eg 100 to 200 users connected simultaneously downloading content that can reach the 100Mbps bandwidth). There are lots of low end routers now that can cope even with 1Gbps bandwidths but fall on their knees when the number of concurrent connections go past 2-3,000 per second. To cope with that amount of connections you will find you need the high end routers – pretty much ISP level routers – and you will find in most cases your “standard” hosting package probably don’t include it. In fact it won’t even be mentioned – I am yet to find a hosting company that will offer a hosting package with X Gb dusk space, Y Mbps bandwidth and Z concurrent connections! Your average company doesn’t worry about that and as such nor do ISP’s. For the rare cases like the one described above you might find that your ISP says “sorry no can do” or they will tell you that this is not part of their standard package and offer you a similar “specialised” package which offers same bandwidth and everything else and also can cope with that volume of connections per second. And quite likely costs you another 5-10k a year 😀 That added cost in most cases is to recover the cost of the high end router mentioned.
You might wonder why do companies not offer this option up front? Well don’t forget that these router have processors and memory and an OS themselves and they do a lot of processing with these; however whereas the standard processing you are used to in computers involve crunching numbers and database transactions, a router processes a lot of IP packets: it has to decide whether this is part of an existing session, where does it need to be sent, what are the best routes to get there, does it match the security policies and ACL’s set and so on. More traffic means more CPU activity so to cope with lots of packets you need a reasonable processor, however more concurent sessions mean the router has to maintain larger in memory structure which will enable it to match packets to existing sessions. Since these structure are going larger that means more lookup operations and that means faster cpu again! A hosting company will provide a regular router which copes with standard traffic for the same reason they offer basic hosting packages: what is the point in offering lots of disk space and cpu and bandwidth when a lot of clients don’t use that much? It’s nothing short of obscene having a quad core server running just an instance of Apache serving simply static pages (even though it is such a common occurrence nowadays!). To provide more power, disk etc means to increase the costs, which is not justified for those clients that don’t need the extras. Similarly, to offer a high end router from the start means a hefty price increase – for something that most clients won’t use (apart from you!), and as such it doesn’t make sense commercially.

So before signing up for a new hosting package with a company and start budgeting around the figure they give you, might be worth reviewing your app connections per second and bandwidth requirements, also review the worse case scenario spikes of traffic and communicate those to your hosting provider – quite likely the price will change, but at least you can address that budget change very early in the project and deliver your solution on time and with no nasty surprises.