Consider using gevent for gunicorn

[sobolevn]

Links:

1. https://pypi.org/project/django-db-geventpool/
2. https://medium.com/@bfirsh/squeezing-every-drop-of-performance-out-of-a-django-app-on-heroku-4b5b1e5a3d44
3. https://docs.gunicorn.org/en/stable/settings.html#worker-class

@AlwxSin what would you say?

[AlwxSin]

@sobolevn not sure that we must force users to use it. In most setups default gunicorn worker is enough. Maybe we should just mention it?

[sobolevn]

Why do you think that gevent should not be the default? What are the risks / problems?

[AlwxSin]

The main reason is that we can't determine an effective number of workers. For classic workers, it's defined in docs (2 x $num_cores) + 1. But for gevent number of workers and number of greenlets in one worker heavily depends on the machine where code runs at.

There is an option to set a fair amount of workers and greenlets by default in the template and add a note for a user. But I'm afraid that some users will ignore that note and wouldn't identify problems in production.

[sobolevn]

Can you please provide a link to this problem? I have never actually knew about it 😆

[AlwxSin]

https://docs.gunicorn.org/en/stable/design.html#how-many-workers

Last two paragraphs.

[AlwxSin]

Ah, I forget to note, that the number of workers we can set programmatically in python file. And use that file as config

[sobolevn]

Sorry, but I am missing gevent-related problems in this doc: https://docs.gunicorn.org/en/stable/design.html#how-many-workers 🙁

[AlwxSin]

Next one =)

https://docs.gunicorn.org/en/stable/design.html#how-many-threads

There is no sign of how many workers and greenlets should be deployed. In fact, I'm surprised that there is really no word about that. So, from my experience, all the numbers should be adjusted for the machine.

[sobolevn]

Do you have any specific formula? We can adjust that to limits in our docker-compose file.

[AlwxSin]

Unfortunately, I don't. It depends on the project's purpose. If it's microservice-like, then 1 worker and 1k greenlets. If it's a big project monolith-like, then several workers (based on cpu count) with 2-2.5k greenlets.

Worth noting max-requests and max-requests-jitter options.

gunicorn server.wsgi:application \
                          -k gevent \
                          --workers 3 \  # three workers
                          --worker-connections 2500 \  # 2.5k greenlets
                          --max-requests 500 \  # each greenlet lives for 500 requests
                          --max-requests-jitter 200  # jitter for previous option

[armenak-baburyan]

I think gthreads could be a good default option too.

https://medium.com/@genchilu/brief-introduction-about-the-types-of-worker-in-gunicorn-and-respective-suitable-scenario-67b0c0e7bd62

If you want a stable system and hope that an exception in one request would not affect other requests, sync is what you need.
If the tasks in your app are almost IO-bound, then async IO is good for you.
If most of all tasks in your app are CPU-bound, then you should consider gthread first.