Asynchrónne controller-y

[Burgyn]

Ahojte, chcem sa opýtať či sa tu niekto vyzná v tom ako sú vlastne spracovávané requesty. Prečo sa pýtam? Viem, že sa dajú spraviť v controller-y asynchrónne metódy na spracovávanie jednotlivých requestov. Ale netuším ako to celé funguje. Čo dotaz to nový thread? Ak áno, tak potom aký význam má asynchrónna metóda v controller-y? Kedy vzniká nový proces? Keď mám singletona, tak mám jednú inštanciu pre všetky requesty?

Vyzná sa tu niekto v tom?

[majco333]

Skúsim popísať čo viem a čo tuším z asp.net 4.5 (mozno je to v Core 1.0 inak). Každopádne za nejaké hlbšie štúdium by to stálo...

Každý web beží v application poole (v jednom poole môže byť aj viac webov) a každý pool má samostatný process - w3wp.exe. Keď príde požiadavka na controller na synchrónnu funkciu a v nej spustíš niečo asynchrónne (napr. cez Task.Run), tak synchro vykonávanie sa ukončí (odpoveď ide na klienta) a asynchro operácia sa dokončí pod w3wp.exe procesom (predpokladám, že v inom vlákne). Ako je to s čisto asychro funkciou controllera neviem. Predpokladám, že sa to ale všetko deje pod jedným procesom w3wp.exe. Singleton je zdieľaný všetkými requestami rovnako ako Cache. Čo je napr. zaujímavé, tak po naštartovaní asynchro funkcie už v nej nie je vôbec dostupný HttpContext, na čo sme pred nedávnom prišli...

Vravím, možno by to stálo za naštudovanie, skúsim niečo o tom pozrieť...

[majco333]

Padol mi do oka k tomu zatial tento clanok: https://msdn.microsoft.com/en-us/library/ee728598(v=vs.100).aspx

Zajtra skusim nastudovat...

[majco333]

Zatial aspon k tomu singletonu: Your static classes and static instance fields are shared between all requests to the application, and has the same lifetime as the application domain. Therefore, you should be careful when using static instances, since you might have synchronization issues and the like. Also bear in mind, that static instances will not be GC'ed before the application pool is recycled, and therefore everything that is referenced by the static instance, will not be GC'ed. This can lead to memory usage problems.

If you need an instance with the same lifetime as a request, I would suggest to use the HttpContext.Current.Items collection. This is by design meant to be a place to store stuff that you need througout the request. For nicer design and readability, you can use the Singleton pattern to help you manage these items. Simply create a Singleton class that stores its instance in HttpContext.Current.Items. (In my common library for ASP.NET, I have a generic SingletonRequest class for this purpose). More: http://stackoverflow.com/questions/194999/are-static-class-instances-unique-to-a-request-or-a-server-in-asp-net

[majco333]

Podla tohto to vyzera tak, ze co synchronny call to samostatny request (ako je to s asynchronnymi zatial neviem):

Let’s take an example, if our application receives just even 100 requests simultaneously and this number of threads are not available in thread pool, then some of them has to wait. CLR starts creating new threads to assign each request. Creating new threads is pretty heavy process and in earlier versions of .net, the rate of creating threads was two seconds per thread while in latest version, it is around 0.5 second. Considering 0.5 sec per thread, creating eighty threads will take forty second so we can understand that the response time would vary at least 1-40 second. You can imagine the situation if number of request goes 500 or 1000.

There is one setting in machine.config which is by default as

Which we can change as maxWorkerThreads = "200" /> As we have set the minWorkerThread count as 100, it will reduce the time spent on creating each thread and IIS will be ready to take the requests quickly. Please note the above settings are on per core CPU basis.

[Burgyn]

Dik za objasnenie. Uzaatváram.