Why use 64-bit?

There are a number of advantages to 64-bit architectures.

• Increased performance with >3GB of RAM – Addressing more than 3GB of RAM in userland on 32-bit linux requires the use a PAE which incurs a small performance overhead, this is not necessary with 64-bit. This can benefit applications that access large amounts of memory such as MySQL.
• Larger memory-mapped files – Particularly useful for a number of key-value/nosql databases such as Redis and others that use memory-mapped files for storage. MongoDB, for example, is limited to ~2.5GB of storage on 32-bit architectures.
• Certain number-crunching applications such as encryption and audio/video encoding can benefit greatly from access to 64-bit registers, offering considerable performance increases.

However, 64-bit isn’t always beneficial! In nearly all cases a 64-bit process will require (sometimes considerably) more memory than an identical 32-bit process due to larger pointers and other data-types occupying more space. This is particularly prevalent with Ruby where many of the internal data structures double in size when switching to 64-bit. Before deciding on 64-bit you should weigh up the pros and cons for your particular application.

That has now changed! Today, we’re really pleased to announce two new dedicated MySQL options: a single dedicated MySQL server and a dedicated HA (High Availability) cluster.

Both services provide you with the benefits of increased performance and predictability with guaranteed CPU and RAM resources, and also include 24/7 monitoring and managed backups!

Pricing starts at just £85/month for a single dedicated MySQL instance and £169/month for the HA cluster – a bargain for what are essentially fully-managed MySQL solutions. They’re available to all customers to purchase from the control panel right now.

For more information, check out the dedicated MySQL services page on our main site.

For further information on using these packages see the release announcement for our Ruby EE 2010.01 packages.

As with our other Ruby EE packages, they upgrade (i.e replace) the standard 1.8 Ruby installation. This means all your gems stay the same, and everything on your system immediately starts using them (Phusion’s own Ubuntu packages do not work like this).

These packages are also the best way to get Ruby 1.8.7 on Hardy, which you’ll need if you’re playing with Rails 3.

If you’re on a Hardy based Brightbox, just create or edit /etc/apt/sources.list.d/brightbox-rubyee.list to contain the rubyee-testing component like so:

deb http://apt.brightbox.net/ hardy rubyee-testing

If you’re on one of our Lucid beta boxes provisioned before today, simply create /etc/apt/sources.list.d/brightbox-rubyee.list and add the rubyee component:

deb http://apt.brightbox.net/ lucid rubyee

Finally, update and upgrade libruby1.8:

sudo apt-get update
sudo apt-get install libruby1.8 irb1.8 libopenssl-ruby1.8 libreadline-ruby1.8 rdoc1.8 ruby1.8

If you’re not on a Brightbox, see the instructions on our wiki first. The wiki also documents how to revert back to the old packages.

We’ve built a bunch of new master-master replicated pairs and our backend systems now distribute customers between them on sign-up. We’ve also been contacting some customers and moving them to new clusters, to relieve the pressure on the main cluster (customers with heavy requirements are still recommended managed dedicated clusters – these will be available to purchase simply as additional products soon). We’re using puppet to automate a lot of the setup of the new clusters and can deploy a new one, with monitoring and backups, very quickly.

This work has almost quadrupled the shared MySQL resources within the space of a couple of weeks, and provides a simple platform to continue scaling indefinitely. The decentralisation also makes some aspects of administration easier, such as arranging downtime for maintenance.

The visible differences are small: rather than everyone connecting to one address, sqlreadwrite.brightbox.net, each account needs to use the address provided in the control panel. The old sqlreadwrite.brightbox.net has become db01.mysql.vm.brightbox.net (the old name will of course continue to work indefinitely), and the new clusters are at db02.mysql.vm.brightbox.net, db03.mysql.vm.brightbox.net etc. Our wiki documentation has been updated to reflect this – customers on the old cluster don’t have to make any changes, it only really affects new customers and customers we’ve contacted to arrange a move.

We’ve also been working on improving the slow query logger to provide more useful results. Instead of reporting every slow query ever logged, it produces an intelligent summary of the week’s queries. This means when you see a slow query in the control panel, it means it’s shown up repeatedly and very likely needs attention, as opposed to queries that just happened to take longer than usual due to load on the cluster. We’ll be rolling this work out just after Christmas.

This work represents a big investment in our shared MySQL platform, which we know is invaluable to a lot of our customers, and allows us to keep growing without sacrificing performance.

sudo apt-get update
sudo apt-get install libapache2-mod-xsendfile
sudo a2enmod xsendfile
sudo invoke-rc.d apache reload

The graphing service is currently in beta, so you might find some occasional gaps in data for the time being, but over time this should prove a very useful feature.

As with our other Ruby EE packages, they upgrade (i.e replace) the standard 1.8 Ruby installation. This means all your gems stay the same, and everything on your system immediately starts using them (Phusion’s own Ubuntu packages do not work like this).  We’ve tested it with the usual Railsy native gems, RMagick, Mongrel, fasthread etc. and have had no problems.

If you’re on a Brightbox, just edit /etc/apt/sources.list.d/brightbox-rubyee.list and change the rubyee component to rubyee-testing:

deb http://apt.brightbox.net/ hardy rubyee-testing

Then update and upgrade:

sudo apt-get update
sudo apt-get install libruby1.8

If you’re not on a Brightbox, see the instructions on our wiki first. The wiki also documents how to revert back to the old packages.

As said above, we now have 64bit packages available too (which was recently made easier by some Debian package dependency updates, also included in our repository).

Please let us know how they worked out for you on our forum. Thanks!

However, we have been working hard over the last week to find an alternative solution and I’m very pleased to announce that we’ve agreed a partnership with New Relic to include their Bronze RPM monitoring service with all Brightbox 512 products and above.

New Relic RPM allows you to monitor 24×7, detect problems in real-time, drill down to find the causes and continuously tune your Rails applications for high performance.

Request your account

We hope to integrate our control panel with the New Relic APIs, but for now to get your free Bronze account:

1. Create a New Relic free (Lite) account, making a note of your account name, and email address used for registering then…
2. Submit a Brightbox support ticket, including your New Relic account name, and the email address to request your free upgrade to Bronze RPM.

New Relic have an excellent Knowledge Base which includes instructions for installing the monitoring agent into your Rails applications and much more.

The Brightbox CDN service works by seamlessly delivering static content (e.g images, css and javascript) to website visitors from a high performance “edge” cache server nearest to their geographic location.

The network of global cache servers consists of 45 Points of Presence (POPs) located in 23 cities, with multiple nodes at each POP – speeding up the serving of assets to a truly global audience.

Brightbox CDN integrates very easily with Rails’ built-in asset helpers. In most cases, customers will need to add just one line to their production environment config:

ActionController::Base.asset_host = "http://assets%d.<appname>.brightcdn.com"

Pricing is per GB, and customers can choose between two simple billing methods, either pay-as-you-go (no contract) or opt for a 12 month commit with significant volume discounts.

For more information, check out the Brightbox CDN service page on our main website. If you have further questions, please get in touch and we’ll be happy to help.

It can be used with the built-in Rails asset host system too, so no heavy modifications or fancy plugins.  We’re looking for some beta-testers, so if you’re interested please drop us an email to hello at the brightbox address and provide us details of your current static asset bandwidth usages if possible. All customers are welcome!

It’s in our testing repository at the moment so give it a whirl (it will of course install on any Ubuntu Dapper box, not just Brightboxes).  We have a page on the Brightbox wiki on how to configure NGINX for your Brightbox apps too (which can easily be adjusted to any NGINX install really).

If you’re playing with any of this beta stuff (like these packages or the Brightbox gem) and have feedback or need help, feel free to discuss it on the Brightbox-beta Google group that i just set up.

The maintenance is to apply some software updates but we’re taking the opportunity to do some MySQL performance tuning at the same time.