ASP.NET async/attendere parte 2

Question

Ho una variazione dei vantaggi di asincrono/await-on-ASP.NET da this question.

La mia comprensione è che l'asincronia non è la stessa cosa del parallelismo. Quindi, su un server web, mi chiedo quanti benefici asincroni/attendi portano alle pagine ASP.NET.

Non è che IIS + ASP.NET sia già molto bravo nell'assegnare i thread per le richieste e, se una pagina è occupata in attesa di una risorsa, il server passerà all'elaborazione di un'altra richiesta che ha del lavoro da fare?

Ci sono un numero limitato di thread nel pool per ASP.NET da utilizzare - async li usa in modo più efficace?

Come ha sottolineato Skeet nel rispondere alla domanda precedente, non stiamo parlando di bloccare un'interfaccia utente. Siamo già multi-thread e la risposta web non può essere completata finché tutte le attività della richiesta non sono state eseguite, asincrone o no, giusto?

Credo che quello che si riduce a questo è:

Quali sono i vantaggi di una lettura asincrona di una risorsa (ad esempio un file o una richiesta di DB) in una pagina ASP.NET contro il blocco su di esso?

Answer 1

se una pagina è occupata in attesa di una risorsa, il server passa semplicemente all'elaborazione di un'altra richiesta che ha del lavoro da fare?

Non credo. Sarei molto sorpreso se questo fosse il caso. È teoricamente possibile, ma molto complesso.

Ci sono un numero limitato di thread nel pool per ASP.NET da utilizzare - async li usa in modo più efficace?

Sì, perché quando si esegue il comando await, il thread per tale richiesta viene immediatamente restituito al pool.

Siamo già multi-thread e la risposta Web non può essere completata finché tutte le attività della richiesta non sono state eseguite, asincrone o no, giusto?

Che è corretto. async in uno scenario server si tratta di rimuovere la pressione sul pool di thread.

C'è qualche vantaggio per una lettura asincrona di una risorsa (ad esempio un file o una richiesta DB) in una pagina ASP.NET rispetto al blocco su di essa?

Assolutamente!

Se si blocca su una richiesta di file/chiamata di servizio/db, tale thread viene utilizzato per la durata di tale operazione. Se si await una richiesta di file/chiamata di servizio/db, tale thread viene immediatamente restituito al pool di thread.

Uno (davvero interessante!) Risultato di ciò è che è possibile avere una richiesta in corso, e mentre è (a) in attesa di qualche operazione, ci sono n. discussioni che soddisfano tale richiesta! Concorrenza a thread zero, se vuoi.

Al termine dell'operazione, il metodo riprende dopo await - su un thread (eventualmente diverso) dal pool di thread.

In conclusione: le scale async migliorano rispetto ai thread, quindi c'è sicuramente un vantaggio sul lato server.

Altre informazioni: il mio intro to async post e this awesome video.