-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ASGI support for later Django versions (works with Django 3.0.x) #22
Comments
I did create a |
I've found the solution for this. Will be implementing this the following week. |
Sorry for few updates on this one, but I can assure that it's being worked on. There's been a few obstacles, but design, pattern and implementation is about to be finished. I've also been in touch with Andrew Godwin regarding a potential memory leak. |
I know I haven't commited any code for anyone to look at, but I want it to be a bit more finished and tested before I let people see. Right now it's not organized, not documented and not pretty. I've tested the memory consumption of uvicorn with and without the async Django-GUID middleware(as the only middleware). It does not matter if I send 1000 requests or 100000, the memory consumption difference is always about 0.13MB. There is no memory leak, only a bit more memory consumption. # 100k requests with Django-GUID async supported middleware
# start memory
353408K
# 100k requests later
670792K
# 100k requests _without_ Django-GUID async supported middleware
# start memory
353400K
# 100k requests later
670924K EDIT: Forgot to write that a GUID is 16 byte, so 100k requests would be 1.6 MB - which is 1.3MB more than the actual memory consumption. |
Busy weeks. Getting there though. |
Coverage is at 100%, docs are almost done. |
With ASGI being stable and more async support to Django is coming up, this package eventually have to change it's design to be ASGI compliant.
ASGI by protocol can handle multiple requests on one thread. Every time
await
is used, the control of the loop will be handed back to the event loop, queuing the resumption of the function. The next function will run until it calls on anawait
, and then the entire thing repeats. This means that a thread will by design be able to handle multiple requests.Most of Django do not support
await
at the moment, sodjango-guid
will work on ASGI today. The way it works right now is that when it gets an ASGI request on the event loop, it dispatches it to a thread pool where each thread again handles one request at the time.Essentially this means that in the future, in order to keep this package living we have to find another ID to use. Luckily the Django people has been kind to us and implemented a replacement for us.
I will look into implementing this ASAP.
Thanks to
knbk
on#freenode
.The text was updated successfully, but these errors were encountered: