1

I am currently approaching stages to move my first large-scale application out of development.

I have talked with some CTOs who know what they're talking about, and I have been advised to do the following:

Break up launching phases into a 4 step process

I. Launch the single structured app. assets/ and db.sqlite3 inside of the application, all on one server.

II. Move the database onto its own server, use a CDN (like aws-s3) to hold the assets/

III. Set up load balancing

IV. Use a NoSQL solution rather than a rdbms.

So! The main question I have concerns item 2:

Do I have to set up an environment to run sqlite3, creating a user, and then giving that authentication specifically to my django application?

I'm familiar with having the assets stored externally, but I've never had to move out the database, excluding non-django solutions that implemented parse.

tldr; I'm an amateur professional developer and I've never built anything that was ever intended to have over 1,000 users, and am curious what the process flow looks like for creating a django application that manages to successfully reduce the server load by using another server.

Where my thinking may be flawed: I don't understand how this distributes the load, since to me it seems that the application would have to make farther requests to communicate with the database. Is it actually just acting as a middleman who passes messages back and forth between the client and server?

Planning to use apache for hosting, likely on a ec2 ubuntu 14.04 instance (multiple?).

Thanks.

jdero
  • 113
  • 5

1 Answers1

2

I am really, really confused by the list you got.

First it tells you to use sqlite3 on a single server. Then it tells you to move this sqlite database to a different host? Then it tells you to set up load balancing (on a single webserver?) then it tells you to use a NoSQL solution when there is no reason at all why a rdms would be a bottleneck from what you've described here.

Anyway, the general setup of a project that you want to host widely like this (and the easy way) is to put the database on a separate host (be it mysql, be it postgresql, what you like) and deploy code to a number of application servers.

You'd use deployment tools or an nfs to make sure the code on all application servers is the same.

In front of that you usually place a load balancer and/or a reverse HTTP proxy to offload traffic that would normally reach your backend servers.

A good solution would be to indeed go with Amazon and use their Elastic Loadbalancer making your scheme look like this:

  • 1 instance of a loadbalancer.
  • 2 (or more) instances of a application servers.
  • 1 (or more) instances of your favourite database server.

You can extend/implode this by running the database server on one of your application servers. You can extend it by adding failovers for your database servers, automatic provisioning, provisioning tools, etc.

ikanobori
  • 136
  • 3