c# - When do you really need async on a web framework? -
async has become buzzword in .net , ms have introduced in web api 2 more requests can handled whilst others waiting on io finish.
whilst can see benefit of this, concern? x64 architecture has 30000+ threads in thread pool unless have many concurrent users on website async required? if have many concurrent users without caching i'm pretty sure sql server fall on many requests?
apart being shiny when there real need have async routing on web framework?
many of other answers here coming ui (desktop/mobile app) perspective, not web server perspective.
async has become buzzword in .net , ms have introduced in web api 2 more requests can handled whilst others waiting on io finish.
async , await introduced in .net 4.5 / vs 2012. however, asp.net has had asynchronous request capability since .net 2.0 - long time ago. , there have been people using it.
what async , await bring table asynchronous code that easy maintain.
whilst can see benefit of this, concern?
the key benefit of async on server scalability. put, async tasks scale far better threads.
@joshua's comment key regarding memory; thread takes significant amount of memory (and don't forget kernel-mode stack cannot paged out), while async request literally takes few hundred bytes.
there's bursting consider. .net threadpool has limited injection rate, unless set minworkerthread count value higher need, when burst of traffic requests 503 before .net can spin enough threads handle them. async keeps threads free (as possible) handles bursting traffic better.
a x64 architecture has 30000+ threads in thread pool unless have many concurrent users on website async required?
@joshua again correct when points out you're thinking of request queue limit (which defaults 1000 iis queue , 5000 asp.net request limit). it's important note once queue filled (during bursty traffic), new requests rejected 503.
even if have many concurrent users without caching i'm pretty sure sql server fall on many requests?
ah, that's question entirely.
i'm giving talk @ thatconference 2013 on async servers. 1 part of talk situations async doesn't (my twitter update).
there's excellent blog post here takes position asynchronous db calls not worth effort. it's important note assumptions in post:
- at time post written, asynchronous web servers difficult. these days have
async, more , more libraries offering asynchronous apis (e.g., entity framework). - the architecture assumes single web server single sql server backend. common setup traditionally, changing today.
where async servers shine when backend can scale. e.g., web service, azure sql, nosql cluster, etc. example: i'm writing mvc/webapi server uses azure sql , storage backend (for practical purposes, can act have infinite scalability); in case, i'm going make server async. in situations this, can scale server 10x or more using async.
but if have single sql server backend (and have no plans change azure sql), there's no point in making web server async because you're limited backend anyway.
Comments
Post a Comment