5

I'm interested in deploying a django application with its database. So I would like to know what do you think what can be better in terms of performance: Three linodes 540 (720) or one linode 1440 (2880).

I would like to have one to serve static content, another serving as application server, and the last as database server.

What is your advice?

Alex. S.
  • 915
  • 2
  • 13
  • 21

4 Answers4

8

I respectfully disagree with chaos' suggestion. Having several VPS won't distribute the load equally, and the VPS that serves static files will be probably vastly under used. Also it increases the complexity of your application.

I'd go with a big fat server, increase its capacity as needed, and only consider partitioning when it's no longer feasible to upgrade it.

Ivan
  • 3,172
  • 4
  • 25
  • 34
  • +1 this was a tough one, but I think I'm going to have to agree with you. Even though multiple VPSs may save you some hassle down the line I think its a bit of a pre-mature optimization. – bendewey May 15 '09 at 03:51
  • 1
    I'd like to also add that hosting the static files from a seperate domain can cause them load in parallel. (eg. http://www.example.com and http://images.example.com most browsers will load content in parallel from both) – bendewey May 15 '09 at 03:53
  • 1
    Thanks. It's not clear from your comment if you meant this, but you can achieve the same effect with just one server. – Ivan May 15 '09 at 04:00
3

I'd go with the three. If they wound up deployed to the same box, you'd be losing a little performance relative to a single VPS, but 1) they probably won't be, 2) it'll be easier to tune them for their roles than to tune a single VPS for all their roles, and 3) it means your application will be designed for distributed roles from day 1, so that if you need to get beefier later, maybe deploy a real server for each role, you're ready for it.

chaos
  • 7,483
  • 4
  • 34
  • 49
1

I'll buck the trend and say that you should go with 2 - 1 for your web content and another (likely bigger) for your DB. Hell, I'm in a situation where I'm running a single VPS for all my needs, including DB, with appropriate subdomains set up:

static.example.org: handles css, js, images, etc content. Set with keep-alives on and future expires on. (content doesn't expire for a year or more, so no further requests are made. Keep-alives on as most web page views will try to load many static pages, so this will speed up these requests)

www.example.org: handle the dynamic requests. Keeping static requests separate from dynamic ones is important for the future scalability of your system - and it's not that much in the way of pre-mature optimization. Set with keep-alives off and future expires off. (content validation must occur with dynamic content. Having keep-alives off (or really low) allows you to save connections for incoming requests... especially when many hits will be single and slower view requests.)

Having nginx as your front-end proxy that handles the static.example.org requests itself but passes off www.example.org requests to a FastCGI backend (for example) has proven to be a speedy solution for us - and a memory conservative one too. Alternatively, you could put all of your static content on Amazon S3 or something and point your web pages to that instead (with future expires on).

My first point of expansion will likely be to move my DB to a separate server. I'll be able to scale out the web server FastCGI processes to multiple systems using nginx easily enough - spreading the load should be fairly easy... in theory.

0

-Vps has memory killer programs one ram allotted exceed . -No logs avalable to check in system . -and if ours apps need more memmory we demand RAM and Hosting providers demand Money . -Best to go mid size VPS plan db-app server distributed .