t3.micro EC2 and production deployment

[LuchiLucs]

Hi!

I'm creating my own web app for the first time and at the same time learning many new concepts so bear with me please.
I have my own t3.micro instance on AWS cloud where I host my django web-app with WSGI trough mod_wsgi and httpd.
t3.micro EC2 instance has 2 CPUs and 1GB RAM.

I wanted to try out deploying through granian w/o the use of a proxy server due to the limited resources (the RAM being the bottleneck in my case, I believe). From your PyCon2023IT it seems the resource usage data were not yet collected, but you designed granian with the edge case scenario in mind. Do you mind elaborating more on this at the current time? Should I try other ASGI applications given my situation?

The second question is about how to deploy through granian. I was thinking about creating a systemd service so that the servers starts every time the machine boots.
To date I use this command boilerplate to run the server with TLS support:

sudo /absolute/path/to/venv/bin/granian \
--interface asgi \
--host 0.0.0.0 \
--port 443 \
--ssl-certificate /etc/letsencrypt/live/mydomain/fullchain.pem \
--ssl-keyfile /etc/letsencrypt/live/mydomain/privkey.pem \
mysite.asgi:application

Do you mind helping me tweaking the other arguments given my scenario? What values should I put and what is the rationale behing it for parameters such as:

  --http [auto|1|2]               HTTP version  [env var: GRANIAN_HTTP;
                                  default: auto]
  --ws / --no-ws                  Enable websockets handling  [env var:
                                  GRANIAN_WEBSOCKETS; default: (enabled)]
  --workers INTEGER RANGE         Number of worker processes  [env var:
                                  GRANIAN_WORKERS; default: 1; x>=1]
  --threads INTEGER RANGE         Number of threads  [env var:
                                  GRANIAN_THREADS; default: 1; x>=1]
  --blocking-threads INTEGER RANGE
                                  Number of blocking threads  [env var:
                                  GRANIAN_BLOCKING_THREADS; default: 1; x>=1]
  --threading-mode [runtime|workers]
                                  Threading mode to use  [env var:
                                  GRANIAN_THREADING_MODE; default: workers]
  --loop [auto|asyncio|uvloop]    Event loop implementation  [env var:
                                  GRANIAN_LOOP; default: auto]
  --opt / --no-opt                Enable loop optimizations  [env var:
                                  GRANIAN_LOOP_OPT; default: (disabled)]
  --backlog INTEGER RANGE         Maximum number of connections to hold in
                                  backlog  [env var: GRANIAN_BACKLOG; default:
                                  1024; x>=128]

[gi0baro]

Hey @LuchiLucs,
first of all a clarification might help on this, since you wrote you're currently using WSGI protocol, but later in your message you talk about ASGI. I know django supports both, but it also does a lot of machinery to turns sync stuff to async, so unless you need a specific ASGI-only feature, I would probably just stick with WSGI also with Granian.

Now, about your questions

From your PyCon2023IT it seems the resource usage data were not yet collected, but you designed granian with the edge case scenario in mind. Do you mind elaborating more on this at the current time? Should I try other ASGI applications given my situation?

So, in my talk I said about the possibility to use Granian on the edge (not edge scenarios), which means without any other server/proxy in front of that. Usually we have additional proxies above Python servers due to Python's limitation, but the rust side of thing in Granian won't suffer from those.
In terms of resources, we're currently investigating a possible memory leak, so you probably want to keep an eye on that, as it might affect your application as well. In general conditions, Granian uses slightly more memory compared to alternatives like Uvicorn, and usually few cpu resources. But there's no official data in comparisons with other WSGI servers at the time being. Probably just a local test might give you some ideas about the resources on your specific application.

To date I use this command boilerplate to run the server with TLS support

Not sure about the sudo, but looks correct to me, except for the ASGI/WSGI theme I mentioned above.
Also, you probably want to issue a SIGHUP to granian whenever you refresh the TLS certificates (if you're using ACME it should be super-easy with the hooks) so that Granian can restarts the workers with the new ceritificates.

Do you mind helping me tweaking the other arguments given my scenario?

Given the specs of your EC2 instance, I'd probably leave everything on default, except for:

• --ws/--no-ws: if you don't use websockets in your application, you can disable those with --no-ws
• --workers: I would test with 1 and 2 which one works better for you, usually 1 worker per CPU is fine, but considering EC2 micro instances have cpu throttling, and also depending on the memory usage of your application, you may have better performance/memory usage with just 1 worker (the default).

[LuchiLucs]

@gi0baro Thanks Giovanni!
Thanks for the tip about sticking with WSGI with Django. I was trying the ASGI protocol thinking about it might be more performant and lighter w.r.t to RAM and timings but I am not aware of any async features of Django that I am exploiting. I believe for now the web-app is a simple static site with server-side forms' validation and computations. I am not exploiting the admin features nor the database ORM models of Django yet.

So, in my talk I said about the possibility to use Granian on the edge (not edge scenarios), which means without any other server/proxy in front of that. Usually we have additional proxies above Python servers due to Python's limitation, but the rust side of thing in Granian won't suffer from those.

I read about serving static files trough a proxy server in front in order to bypass the dynamic WSGI protocol to be faster. Also Django magic for static files directly trough WSGI seems to work in debug mode only. The deployment guide for static files from the same server is here: do you know how to tweak it for granian?

In terms of resources, #276, so you probably want to keep an eye on that, as it might affect your application as well. In general conditions, Granian uses slightly more memory compared to alternatives like Uvicorn, and usually few cpu resources. But there's no official data in comparisons with other WSGI servers at the time being. Probably just a local test might give you some ideas about the resources on your specific application.

How would you test locally the resource usage in my case easily? 😳

Not sure about the sudo, but looks correct to me, except for the ASGI/WSGI theme I mentioned above.

I still have to investigate how to host on higher ports and remap on 443/80 locally on the EC2 instance or trough some cloud networking services: still learning here 😳

Given the specs of your EC2 instance, I'd probably leave everything on default, except for:

--ws/--no-ws: if you don't use websockets in your application, you can disable those with --no-ws
--workers: I would test with 1 and 2 which one works better for you, usually 1 worker per CPU is fine, but considering EC2 micro instances have cpu throttling, and also depending on the memory usage of your application, you may have better performance/memory usage with just 1 worker (the default)

I believe I am not using websockets, so I will try to disable them and leave the default 1 worker. In the case of WSGI, 1 worker means that the dynamic python app code is run in a single sync thread? Having two CPUs "I was thinking about dedicating" 1 process to the rust event loop and 1 process to the python interpreter if that makes sense.