Please, specify. Given the situation of one request being made to one view, explain how the addition of the creation of an event loop in which to run this view will reduce the time required for its execution.
Only true when the requests themselves perform operations that are constrained by the time necessary to perform operations external to that process (e.g. I/O)
Every context-switch, every dispatch to the event loop, every change in processing context costs time. The CPU waiting for an I/O to complete (“blocked”) at the point where it needs to continue is going to require less time to resume that process than if an event loop is going to receive the notification that the I/O has finished and then dispatch to the waiting process.
In an extreme case, if you have a CPU-intensive view that doesn’t access the database at all, it’s not going to matter if you’re running sync or async - you are effectively limited one request per core.
Again, there’s a large number of sites where this isn’t true. Not everyone is running Facebook, Twitter, Instagram, YouTube, etc.
Multiple requests / second probably translates to a minimum of 100,000 requests / day. I know more people than not that are hopeful for 100,000 requests / month.
I’ve talked to a fairly sizeable number of people at events like DjangoCon or PyCon regarding the sizes of their deployments. In terms of number of sites based on Django, my (informal and unsupported) impression is that there are a lot more that don’t see activity anywhere near the range of 1 request / second.
Most do - at least some datastore - for the User object to populate
request.user or for session support. But I do acknowledge that it’s not universally true.
Also not universally true, and not necessarily accurate. It’s also possible that they all time out because the net latency caused by the number of requests in total exceeds the capacity of the system to handle them. (e.g. A CPU-bound view as mentioned above.)
That’s one of the edge cases I referenced earlier. I continue to acknowledge the usefulness of async in those situations. I just don’t think it’s as prevelent as you appear to want to make it seem. (An opinion, yes. But in 10 years now of working almost exclusively in Django, I can still count on one hand the number of times I’ve needed to do that.)
Hmmm… It doesn’t look like django is losing anything based on that graph. Thank you for confirming my point. (That they aren’t showing the same rate of growth as a different product really isn’t relevent to me. What I see in that chart is a gradual increase, by month, of Django downloads.)
But anyway, look, I know you have been beating the drum trying to drive async develompent here for more than a year. I applaud your persistence.
I just have no use for it - at least not to the degree that I’m willing to sacrifice the performance and ease of development of synchronous Django for its adoption.