Are earlier versions of the Django Development Server single-threaded? When I have multiple users going to the same page, the second person has to wait for the first person’s page to load before they can enter. What solutions do I have to fix this?
For context:
I am using Django 2.2.1 (cannot update this due to company policy).
I am running Windows, and have daphne in the project
I have read this topic: Is Django development server single-threaded? but I cannot update. I also tried using Uvicorn to run the project (which has multiple workers and that works, but it services Websockets much more slowly than Daphne/Channels).
Django 2.2 is not async in any way. I don’t see any possible value with using Daphne in that environment. Additionally, Daphne requires Python 3.8 or later, and Django doesn’t support Python 3.8 until Django 2.2.7, so you’re already using an unsupported combination of components.
At best, I would suggest using either gunicorn or uwsgi for the Django side, and reserving Daphne for the channels-related components.
I’m a bit confused right now. Sorry if my questions seems simple, I’m new to this.
I’m using Django 2.2 on Python 3.6.8, and I’ve installed Channels 3.0.3 (channels · PyPI). Associated with that is daphne 3.0.2 (daphne · PyPI) which should support Python 3.6 and later.
I have websockets in my applications and set up all the routing, everything works fine in production (no delay, nothing). When I call python manage.py runserver 0.0.0.0:8000, is the production server using Daphne? My websockets are all working fine, but the only issue is that HTTP requests are happening in series, not parallel. Does this mean I cannot handle concurrent requests using only Django’s built-in server?
If I cannot, what solutions do I have? As discussed earlier, I’ve been trying Uvicorn to add more workers but the performance is undesirable. Can Gunicorn or uWSGI be used in a Windows OS setting? Thanks for your help!
Possibly, that depends upon the configuration of your project.
However, regardless of the above, I’ll point out the following from the runserver docs
DO NOT USE THIS SERVER IN A PRODUCTION SETTING.
Using Daphne is one thing, using the runserver wrapper around it is something else entirely.
For historical reasons that may (or may not) now be fixed, we always run two separate servers for our Django / Channels projects. We use uwsgi for the Django side and Daphne for the Channels side only, both running behind nginx as the web server. (We still deploy that way as we have no current use for async Django.)
Side note: I never accept excuses that such-and-such can’t be done due to “Company policy”. Company policies can be changed, and generally can be easily changed when you can demonstrate the potential legal liabilities of not changing a policy, in this case, the introduction of security vulnerabilities from the use of outdated and unsupported software versions.