Basic questions about scaling a Django web app. (e.g. AppEngine solves all problems?)

[cseb...@gmail.com]

I have a simple web app (bighelp.business).  I anticipate

the number of users to steadily increase.  

I'm having nightmares of having to guesstimate how much

extra RAM and cores to add every week.

Furthermore, WSGI has these switches I use...

--processes=5 and  --max-requests=50.  I don't know how

I should alter these as my userbase grows and I don't want

to guesstimate.

How to others deal with growth?  By the way, if I port

my Django app to Google App Engine, does it automatically

solve all these problems or is that just wishful thinking?

Thanks!

Chris

[Andréas Kühne]

I would say that Google App Engine MIGHT solve some of your problems, but you will instead get more problems. App Engine is a good solution, but still is a big black box of functionality.

I think you would be better suited with a solution like Elastic Beanstalk from AWS (there probably is an equivalent version in Google Cloud as well). What you need to make sure is that your app is stateless (no local saved items, media and so on) and that the database is on another machine. Then you can scale both horizontally (add more cheap machines) and vertically (add more CPU power and memory). I run an online store that does this automatically. All that happens is that I get an email saying that 2 more machines were provisioned or shut off. We always have 2 small machines running - and the system scales up when needed.

Best regards,

Andréas

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7bb16367-44fa-4593-9826-968a0084adbbn%40googlegroups.com.

[Robert Seghedi]

Just go for Cloudflare Pages. It s much more easier

--

[Christian Seberino]

Thanks.  I'll check it out.

You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/B-wX6Qe4EtI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAP1Y9dT74%3D0bF2OXC%3DMjXFfUN42_tZYFCDAz6ZKYN__eczzdhQ%40mail.gmail.com.

[Christian Seberino]

Beautiful.  Thanks.

You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/B-wX6Qe4EtI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK4qSCeE-FsDPDqfYcu67d5bRvwGCEd9WJ_thHXgvGOQM611cw%40mail.gmail.com.

[Stephen Loughin]

I have this question too, but I'm running on an intranet on a self-hosted box under docker.  My docker-compose.yml file is structured to have the following services:
redis-db
web-api
rq-worker (scalable, typically with 4 workers)
nginx 

I don't have the luxury of putting this in the cloud.  The worker threads make calls to the web-api to set / get items in a backend database and now I'm finding that the web-api might need scaling too.  Has anyone set up a docker stack with nginx as a proxy / load-balancer with a scaled web-api?  Alternatively, I could (rather than scaling) name the web-api copies: e.g. web-api-one and web-api-two.  I'm thinking most of what I'm looking for is how to configure nginx to use both web-api copies.

Here's the relevant part of my nginx local.conf file:
# first we declare our upstream server, which is our Gunicorn application
upstream onix-api-server {
   # docker will automatically resolve this to the correct address
   # because we use the same name as the service: "onix-api"
   server onix-api:8000;
}

# now we declare our main server
server {
   listen 80;
   root /;
   index /public/index.html;
   access_log /var/log/nginx/access.log;
   error_log /var/log/nginx/error.log info;

   ...

   location @default { # location / {
      # if try_file fails we then pass it to Gunicorn
      #include cors_support;
      proxy_pass http://onix-api:8000;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header Access-Control-Allow-Origin *;
      proxy_redirect off;
   }