# What does switching to ASGI entail?

**URL:** <https://forum.djangoproject.com/t/what-does-switching-to-asgi-entail/26857>\
**Category:** Async/Channels\
**Created:** [January 11, 2024, 7:14pm UTC](https://forum.djangoproject.com/t/what-does-switching-to-asgi-entail/26857 "2024-01-11T19:14:44Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [January 11, 2024, 8:36pm UTC](https://forum.djangoproject.com/t/what-does-switching-to-asgi-entail/26857/2 "2024-01-11T20:36:51Z")

</div>

> [@realsuayip](#):
>
> I know that unlike WSGI threads, ASGI threads can work on multiple requests. Thanks to this, you have access to some functionality such as efficient streaming with `StreamingHttpResponse` (without blocking the entire thread). This also means that overall, you’ll have better throughput since more threads will be available to process requests.

Actually, as written, this isn’t exactly correct.

At the most fundamental level, ASGI runs everything in one thread. It relies upon the code being run to not tie up that thread any more than absolutely necessary.

So no, you _won’t_ have better throughput overall until you reach the point where you’re handling enough requests that can be “event driven” instead of “process driven”. Handling 4 concurrent requests in 4 separate processes is going to take less time than handling those same 4 concurrent requests in a single thread if those requests are more CPU-bound than IO-bound.

You’ll only see a benefit if your views are spending enough time waiting for data rather than processing the data.

> [@realsuayip](#):
>
> All of these are good and all for async views, but what happens when you have only sync views?

It will run those views in a separate thread from the thread running the event loop. (See [Asynchronous support | Django documentation | Django](https://docs.djangoproject.com/en/5.0/topics/async/#sync-to-async))

> [@realsuayip](#):
>
> switching to ASGI in a sync project should come with near zero-overhead if not making the throughput any better.

This is not correct. A single-thread multi-process runtime is going to be faster for a single request than the overhead of an event loop. When you’re writing async code, say an `await` statement, you’re releasing control of the CPU back to the event handler. This creates overhead compared to the case where you’re keeping control of the CPU, possibly doing a “busy-wait”, while you’re waiting for your IO request to complete.

> [@realsuayip](#):
>
> Should I switch to ASGI?

That really does depend upon your application. There’s no doubt that there are a set of applications, conditions, and circumstances that are _greatly_ enhanced by an async approach.

However, I maintain that those situations do _not_ exist for 99+% of all Django development being done. No, I don’t have any proof of that. I’m not aware of any survey or research to prove or disprove it. But the number of sites that deal with [“Facebook”, “X”, “Instagram”, “Amazon”, “Google”]-levels of traffic are _exceedingly_ small. The number of sites that may aggregate data from multiple sources where parallel web requests or database queries would provide a tangible benefit is likely to be a much larger number - but I think that is still relatively small.

> [@realsuayip](#):
>
> How do I properly test which one is better for my application?

I think your first “test” is to evaluate your code and your project along with your (realistic) projections of the level of activity your project will see.

Again, async does not improve the throughput of CPU-bound tasks. It increases throughput in those areas where the tasks are otherwise waiting for IO to complete by allowing the CPU to work on other things.

---

_[View the full topic](https://forum.djangoproject.com/t/what-does-switching-to-asgi-entail/26857)._