Django and concurrency

Hello everyone
I’ve been working as a Node.js developer for a while, a few months ago for some reason I decided to learn Django.
As you already know Node.js works asynchronously but Django does not (Not by default at least).

Here is my question: since Django runs under WSGI and WSGI can only process a single request at a time, let’s say we have an endpoint and every request takes 10 seconds at least, If I have only one service worker, what happens in this case? Does this mean my Django server could only process 6 requests per minute?

I appreciate someone could clear this up for me


In general: yes. But in practice that’s not as problematic as it seems. Because

a) you don’t want to have a request taking that long anyway. So you would use caching to speed it up or a separate task scheduler (celery usually) to execute long running tasks independently from the request cycle.

b) you can spin up as many worker threads as you want (using eg. gunicorn). Those are not running in parallel (thanks to python’s GIL) but are interleaved. That works well if your task is I/O bound and therefore is waiting for eg the database most of the time.

1 Like


c) You are encouraged to run multiple worker processes as well, up to 4 times the number of cores you have on your CPU. These separate processes do run in parallel, and so can handle those cases where your tasks are somewhat CPU bound.

1 Like

Thank you for your response
I’m fully aware that I should move long-running tasks to a background job (e.g. using celery and rabbitmq) and speed up my database access using indexes, caching, etc and I should have multiple worker processes.

My projects are I/O bound most of the time and I’m concerned about threads being idle and the fact that other requests must have to wait until the previous request finishes.

What if my database gets over 2 million records?
Was that a bad idea to use Django for my I/O bound project?
Should I use Node.js instead?

By the way, My project is a doctor appointment booking system
Thanks for the clarification

Do you have actual metrics demonstrating a problem? Or are these simply conjectures based upon other information?

Trivial, if your database, models, and queries are designed correctly. PostgreSQL is going to handle that without breaking a sweat.

Since the work to retrieve that data depends upon the database and not the application framework, it doesn’t matter which framework you choose.

Not at all. If you’ve got delays caused by the size of the database, then you’re looking at solving the wrong issue. If you’ve got problems managing only 2 million rows, then your issue is the database and not the framework.

That’s your decision - and given that at the scales we’re talking about, the choices are effectively identical from a technical perspective - it’s a decision that should probably be based on non-technical factors. (Knowledge of the frameworks and associated libraries, comfort with the ecosystem, etc)

1 Like

Thank you so much for the clarification
So essentially it’s not a big deal most of the time by leveraging multiple workers

It has never created a problem in the 10 years that I have been deploying Django projects.

1 Like

Thanks again for your response