Archive: posts from August 2007

IP addresses and Google UK 24 Aug 07

Following on from John’s post earlier this week about the low latency benefit of our UK based servers (over US based competitors) for customers/websites with a European audience, there is another factor to consider. Google.

As Google’s Webmaster Help Centre explains:

While all sites in our index return for searches restricted to “the web,” we draw on a relevant subset of sites for each country restrict. Our crawlers identify the country that corresponds to a site by factors such as the physical location at which the site is hosted, the site’s IP address, and its domain restrict.

That said, your site’s domain doesn’t need to match the country domain for which you’d like it to return…

Now, I can’t really see how Big G can work out the first “factor” (physical location) without the second (IP address), using some sort of IP geolocation data. So as far as I can see, if you want to appear in the “pages from the UK” set of results in Google UK, having a UK IP address is an important factor.

VAT camp 22 Aug 07

This could well be *the* dullest subject to blog about – but since there always seems to be a fair amount of confusion over VAT (Value Added Tax) and to whom it should be charged, especially when selling goods or services internationally, I thought it would be useful to explain how we’ll be implementing VAT into our payments system for Brightbox.

No? well ok, don’t worry. But if you’re interested or have nothing to do, read on…

Read the rest of this entry »

It’s the latency, you see 20 Aug 07

I saw this question about Brightbox on a forum today:

what would be the advantages of hosting with a UK company over a US based company

One simple repercussion of hosting a site for a European audience on an ISP in the USA concerns trans-atlantic connectivity, which increases latency. If your ISP is on the West Coast it’s even worse.

Some casual ping testing from a machine in the UK to a number of Rails hosts in the US showed between 95 and 161 millisecond round trip times. With HTTP ping testing I was seeing up to 327ms, which is likely due to the TCP handshake consisting of at least 2 packets before the request is even issued. From the same machine to a Brightbox (different ISPs of course) I saw around 15 milisecond ping RTT and 33 millisecond HTTP.

Average Ping RTT graph (smaller is better)

Average HTTP RTT graph (smaller is better)

With HTTP features such as persistent connections you can reduce the impact of the TCP handshake, but with these hosts your European visitors will still see up to 161ms delay before your Rails application even starts processing the request. Fragment caching won’t help you much there. With the new breed of AJAX web applications this is a huge impact on how responsive things will feel to your visitors.

This wasn’t a scientific test with double blind trials, lab coats and conical flasks but it gives you an idea of what a difference 5,500 kilometers makes.

When Brightbox met Kodefoo 17 Aug 07

I popped over to the GeekUp Leeds event on Wednesday at The Lounge. It’s a fairly new event (in Leeds anyway) and it was my first time, but it was fun to catch up with Rob Lee (of Kodefoo). We’ve been using the now infamous Apache 2.2 package that Rob backported from Ubuntu Feisty to Dapper for quite some time now, but completely unaware that Rob/Kodefoo is based only a couple of miles away in Otley!

Such a small world, eh?

The “branding” of Brightbox 16 Aug 07

As you might have noticed, we’ve started to roll out a new logo. Up until a week or so ago, Brightbox was just a name we were using – there was no “branding” or logo as such, so I thought it was about time I put my designer hat on and came up with something! After days of playing about into Fireworks with different shapes and styles it was all looking either too clinical or “corporat-ey” or too “web2.0-ey” – just couldn’t find something that worked.

So, resorting to the good old pen and paper, I tried just sketching out a couple of ideas.

Three minutes and two pages later, there it was :)

From rough sketch to finished “box” took 4 steps (and another 4 minutes):

1. “Scanned” in the sketch by taking a photo on my mobile (Sony Ericsson K800i)
2. Sent the photo to my Mac via Bluetooth
3. Increased the brightness/contrast in Photoshop to make the lines clearer (flickr)
4. Imported the image into Illustrator and used the “Trace” command to simplify the edges and convert to vector (flickr)

Done. Not bad for 10 minutes work or so?

Brightbox Pricing 10 Aug 07

Over the last few weeks we’ve been putting more thought to the pricing structure for Brightbox and have settled on the following provisional price matrix, which we think offers great value for what’s included:

Each Brightbox includes

• Customised Ubuntu 6.06 OS preinstalled
• Brightbox Ruby on Rails stack
• Apache 2.2/Mongrel
• Monit for managing Mongrels
• Subversion repository
• Outgoing mail relay
• Guaranteed (yet burstable) CPU resources
• UK IP address
• Root access
• Mirrored MySQL db cluster
• Mirrored RAID disk storage
• Juniper Networks firewalling
• Free Gigabit traffic between additional Brightboxes
• Fully redundant public network
• UPS and Generator power

Optional extras/upgrades

• Additional bandwidth/data = £5 per 5GB/month
• Additional storage = £10 per 5GB/month
• Custom firewall rules = £10 per month
• Extra IP address (e.g for SSL) = £25 setup

EXCITING NEWS!

We’ll be offering 100 special launch accounts which will feature a sweet discount – pay for 6 months and get 6 months free!

These special discounted accounts will only be available for 2 weeks after launch, and will be offered firstly to those who have participated in the beta programme and then those on the announcement email list, before being offered to the rest of the world. So signup to the mailing list here and make sure you get your hands on one of these special Brightbox accounts.

¹ Rather than limit the number of databases you can create, each Brightbox comes with a limited number of concurrent connections to the MySQL database cluster

² Prices quoted are exclusive of VAT where applicable

Why we chose Ubuntu Dapper Drake 3 Aug 07

We’ve had a few beta testers ask about why we chose Ubuntu 6.06 (Dapper Drake) as our primary Xen guest installation, as opposed to one of the more recent releases such as Edgy or Feisty. We chose it primarily because of its support contract.

Ubuntu’s release schedule sees a new version released roughly every 6 months. These releases contain the very latest versions of the software packaged with it and are supported for only 18 months. Once in a while a version is selected as Long Term Support release (LTS) which gets 5 years of server support (3 years for desktop). By support, I mean the Ubuntu team are committed to releasing security upgrades in a timely manner. Dapper was the first LTS version and is support through to June 2011.

If we’d chosen Edgy, security upgrades wouldn’t be available to us after April 2008, forcing all of our Brightboxers to upgrade to Feisty, and so on every 18 months. With the speed that the Rails community jump deployment strategy ships some might say this isn’t a problem, but most installations do need long term stability and Dapper provides that.

There are some issues though, mainly that Dapper’s version of Apache is too old to support the nice proxy balancing stuff that’s used for Mongrel deployments¹. To solve this, we chose to use a backported Apache package². This does mean that we have to commit to backporting all security fixes, but this is trivial compared to all our guest machines needing a full upgrade every 18 months. We still get the Ubuntu team working for us on the other 99.9% of packages.

For our users who like to ride the bleeding edge, they can still upgrade to Feisty themselves if they know what they are doing but for most, this isn’t what Brightbox is all about.

¹ A beta tester pointed us in the direction of this bug report requesting an official Apache backport for Dapper. The more people testing these packages and voicing their support, the more likely this might happen.

² We’re using the backported Apache package provided by kodefoo.com at the moment (http://www.kodefoo.com/2007/2/18/deploying-rails-on-ubuntu-dapper/) but are ready to roll our own if necessary.