Hosting improvements - more, more, more
By Joe on Monday 23 February 2009, 18:00 - Gandi - Permalink
So here we are, proud parents of the Gandi hosting infrastructure. Our little baby has now been live (or alive) for 4 months now since the full launch on 1st Oct. Like any new parent everything is possible for our hosting baby, and the future is really exciting. But also like any new parent, there is lots to learn and always things to be done.
The reaction to the product has been great, and the industry is becoming more and more agreed that hosting products based on cloud infrastructures will be the future. In fact Gandi was recognised in the Tier1Research Industry report on Hosting as a company and service to watch:
"Gandi has all the hallmarks of a true cloud infrastructure service, with scalability, redundancy against single points of failure, and flexible, pay-as-you-go billing schemes." - Tier1Research Winter 2008.
But we are not going to rest on our laurels. In fact since we launched the full service we've been monitoring performance, taking feedback and putting in place additional tweaks and fixes to optimise our infrastructure. And today we are pushing out the first set of improvements!
Based on the analysis of existing customers (over 5,000), their usage patterns, needs and performance, we have been able to double (yes double) the CPU limits available to each and every share on our system. This means that you will be getting more bang for your buck, with no compromise in performance. It will also continue to ensure that the more shares you buy the more CPU you get, as performance has been doubled at every level.
And you can feel good about it too! Too many servers run at only 10-12% utilisation (based on recent data published by Dell and confirmed by Gartner), which means the hosting industry produces a lot of waste! This has always been one of the benefits of virtualisation: use servers more efficiently, cut waste, be more green. So a feel good side-effect of this improvement is that the servers will be better utilised, so you benefit and so does good old mother nature.
But that's not all. We've also made a dramatic improvement to the IO wait for filer access with a few well targeted fixes in the device drivers. So again you'll notice the extra zip in your share.
We've also seen more people using Gandi Flex (our flexible share booking system to allow you to scale your resources on schedule), so we wanted to say thanks by lowering the price per Flex share from €0.07 ($0.10/£0.06) per hour to €0.03 ($0.05, £0.04) per hour. So this is yet another way to up and down scale your needs.
And finally, if you're not convinced, we're giving new customers the opportunity to test drive the Gandi system. So if you have any doubts, go to our hosting page and submit a request for a hosting test drive and we'll give you some shares to have a go.
We hope you enjoy the improvements, and you can be sure that we are working on more. Now back to work 
Comments
Your data about CPU utilization reminds me of a couple of questions I have about Gandi's hosting service.
Do you have Xen configured to strictly partition CPU resources and not allow domains to exceed them, or can one domain take more CPU if another domain falls idle? The latter seems like a better way to ensure that CPUs stay near 100% utilization at all times.
Also, given how Xen does virtual I/O through domain 0, you should have Xen configured so that domain 0's VCPUs get dedicated physical CPUs which nothing else can run on. This will significantly improve I/O performance.
Hi,
Yes, driver domain has guaranteed ressources for virtual I/Os.
Today xen is configured with strict (credit) partitionning, equally important domains.
You get a fixed amount of credit with each share.
However, we do not want the share to appear excellent at the beginning (because you're alone on a node, you get full idle cpu for yourself) and degrade over time with no user idea of when it will stabilize. As people can try our servers "for a few minutes", that would be kind of lying. We want the user to experience an expected, stable performance level.
So we slightly overcommit on the credit, and as we'll get better at migrating vms accross nodes to achieve a little balance, we'll probably overcommit a little more.