New "multi-machine" feature
Posted Apr 4 at 08:59 CDT by Remi in General - 9 comment(s)
We just rolled out a new feature in the control panel: a single account can now manage applications, websites and databases on multiple machines. This allows you to:
- Load-balance your site between multiple machines (by default the load-balancing is done at the DNS level).
- Migrate your site to a different machine without any downtime (your site can be up on both machines while the DNS change propagates).
If you want your account to have access to multiple machines just open a ticket and ask for it. Note that you'll have to purchase a second plan for your apps and sites on the other machine.
Remi.9 comments:
Manuel said on 2007-04-04 11:01:19:
With WebFaction shared plans every customer has currently access to a single machine. Ideally he should have access to three different shared machines with different setups.As an example the Django ideal setup is split into three different machines:
1. web server
2. media server
3. database server
The media server (static content) should run a stripped-down web server optimized for static media deliver (lighttpd and tux are both excellent choices here, but a heavily stripped down Apache could work, too).
With the new "multi-machine" feature in theory a user should purchase three plans to implement the ideal Django setup. Am I right?
Remi said on 2007-04-04 12:20:26:
Manuel: Well, if you want to use three machines and only use one service on each machine you can do so. Yes, you will have to pay for each service that you use on each machine but if you don't use all the features of a full plan you don't have to pay for a full plan on each machine.Remi.
Manuel said on 2007-04-04 12:37:39:
Hi,in fact I was thinking about shared media servers optimized for static media deliver (without any app running on) where WF customers can place their static files to boost performance. Probably you could include this service at no cost starting with shared 2 plans for customer more sensible to site performance.
As for the database server, DreamHost don't place its databases on localhost but on different dedicated servers; instead WebFaction, correct me if I'm wrong, places the database on localhost mixing web and database servers on the same machine. Is the DH approach more powerful in terms of overall performance?
Thanks
Manuel said on 2007-04-04 12:47:12:
As for the media server, of course it's necessary an adequate demand level from customers to economically justify a server dedicated exclusively to serve static content but I think many Django users could be interested.As an example I've read on his blog that Mr Jeff Croft has his Django apps hosted on WF and his static files hosted on DreamHost. I think he does not have any performance advantage from this setup since the DH server is a normal web server and its setup is not optimized for static media deliver. So this kind of users could be interested to the dedicated media server offer.
David Sissitka said on 2007-04-04 22:43:44:
Manuel: Jeff Croft still has a Dreamhost account because of the amount of disk space they offer:http://www2.jeffcroft.com/blog/2006/dec/22/webfaction-painless-django-hosting/#c20165
I don't know about giving static content servers their own box but that might be a good idea for MySQL and PostgreSQL. If you really need this kind of flexibility and optimization you might want to go VPS or even dedicated.
Jeff Croft said on 2007-04-06 10:54:41:
Hey guys. To be clear about what I'm doing...I have both my Django apps and the "core" static files for my site (CSS, images, JavaScript, etc.) on WebFaction. I use a django application and a static server application in the WebFaction control panel to serve this stuff. So, 90% of the stuff on my site is served from WebFaction alone.
I do have a Dreamhost account still -- as David said, I keep it because of the bandwidth and disk space they offer. In particular, I need it for my mail (I store over 40GB of mail on IMAP, which I wouldn't be able to do with WebFaction). But, I also use it for larger files and downloads from my site (audio, video, etc, etc.), and also for Mint, because I already had a DB and everything set up over these and it was simpler to keep it there than move it to WebFaction.
For the most part, all of my site is on WebFaction. There's just a few larger files and downloads I keep on Dreamhost -- and I use Dreamhost for my mail.
Manuel said on 2007-04-06 12:34:47:
Jeff,thanks for your clear explanation.
What I'm proposing here is a new kind of shared hosting, ideal for modern database-backed web applications in Python or Ruby. Ideally a host should have three kind of shared machines optimized for different tasks:
1. web servers (web apps' dynamic core)
2. database servers (PostgreSQL or MySQL)
3. static servers (static files: css, javascript, images, video, audio, cached pages)
Each customer should be able to access with his account three different machines.
Of course there are many technical challenges to implement a similar hosting offer and this is only a suggestion to WebFaction's innovative team. Moreover I can't extimate the effective performance boost. In any case the new "multi-machine" feature is an essential feature in the scenario I've just descripted.
For someone interested in this topic Django Book's Chapter 21 (Deploying Django) is an excellent read:
www.djangobook.com/en/beta/chapter21/
eas said on 2007-04-07 02:07:06:
Manuel, it seems to me that the architecture you are describing is overkill for shared hosting.The main reason for having a separate media server is that its more memory efficient than serving content from the same apache server that is loading mod_python. Mod_python requires quite a bit of memory, and that memory is wasted if the thread/process is serving static content. The thing is, WebFaction already provides two separate webserver instances to each user (plus there are other options). They have one (let's call it the app server) that runs mod_python and the users Django application, and a shared instance that proxies requests to each users app server, and also can serve static content. This isn't as memory efficient as using lighttpd, but it has the operational efficiency that webfaction only has to support one piece of software (apache) rather than two (apache and lighttpd). It also simplifies things for customers, because they only have to worry about uploading files to one box.
As for splitting the database server off to another machine, there are certainly hosts that do this. Pair.com, where I host my main site, has a pool of database servers, and each time a user requests a new DB, it could be provisioned on any of them. Putting the database tier on separate hardware has some advantages, it allows each to be optimized for the task at hand, but the downside is added operational complexity (plus it adds latency to the act of opening a new database connection).
Its also not clear to me that making the split would be a big win. Database servers tend to be limited by disk I/O speed and available memory. Webservers are generally limited by network bandwidth, and, in the case of dynamic applications, by CPU. If you run them all on a single machine, they don't step on each others toes too much.
At some point though, they start tripping over eachother. At that point, it's time to consider splitting things up, but in a shared hosting environment, it's probably simpler to either encourage the user to upgrade to a virtual private server(s) or migrate load off to another shared machine.
It looks to me like the webfaction control panel may already be designed to allow databases to be provisioned on separate servers.
Splitting things up lets you tune each system for the task at hand. It also lets you make sure that maximal resources are available for the components that are most difficult to scale horizontally (often times, it's the database).
If you want to play with multi-machine configurations, I'd suggest either getting virtual private servers, or some cheap self managed servers, or just set them up at home and load test against them. It can be fun. I'll be honest though, the reason I'm using shared hosting is that it's cheaper and easier.
Remember, "Premature optimization is the root of all evil"
Splitting services (mail, database, static content serving, application server) makes sense and we have already started doing it by using dedicated mail servers (our mail servers use to be on the same machines as the rest).
I'm not sure if we will continue separating other services but if we do the next one will probably be databases.
As for static content serving, I haven't done any serious benchmarking but I suspect that separating it doesn't bring *that* much benefit (and it adds the complexity of having to store your files on another machine).
Remi.