[C#] ¿Cuándo debería usar Async Controllers en ASP.NET MVC?


Answers

Puede encontrar útil mi artículo de MSDN sobre el tema ; Tomé mucho espacio en ese artículo que describe cuándo debe usar async en ASP.NET, no solo cómo usar async en ASP.NET.

Me preocupa el uso de acciones asíncronas en ASP.NET MVC. Cuando mejora el rendimiento de mis aplicaciones, y cuándo, no.

Primero, entiende que async / await tiene que ver con liberar hilos . En aplicaciones de GUI, se trata principalmente de liberar el hilo de la GUI para que la experiencia del usuario sea mejor. En las aplicaciones de servidor (incluido ASP.NET MVC), se trata principalmente de liberar el hilo de solicitud para que el servidor pueda escalar.

En particular, no:

  • Haga que sus solicitudes individuales se completen más rápido. De hecho, completarán (solo un poquito) más lento.
  • Regrese a la persona que llama / al navegador cuando lo await . await solo "cede" al grupo de subprocesos ASP.NET, no al navegador.

La primera pregunta es: ¿es bueno usar acción asíncrona en cualquier lugar de ASP.NET MVC?

Diría que es bueno usarlo en todos los lugares donde estés haciendo I / O. Sin embargo, puede que no sea necesariamente beneficioso (ver más abajo).

Sin embargo, es malo usarlo para los métodos vinculados a la CPU. A veces los desarrolladores creen que pueden obtener los beneficios de la Task.Run en sus controladores, y esta es una idea horrible. Debido a que el código termina liberando el hilo de solicitud al tomar otro hilo, entonces no hay ningún beneficio en absoluto (¡y de hecho, están tomando la penalidad de los conmutadores de hilo adicionales)!

¿Debo usar palabras clave async / await cuando quiero consultar la base de datos (a través de EF / NHibernate / otro ORM)?

Puedes usar los métodos disponibles que tengas a mano. En este momento, la mayoría de los principales jugadores admiten async , pero hay algunos que no lo hacen. Si su ORM no es compatible con la async , no intente Task.Run en Task.Run ni nada de eso (consulte más arriba).

Tenga en cuenta que dije " podría usar". Si está hablando de ASP.NET MVC con un único back-end de base de datos, entonces (casi con certeza) no obtendrá ningún beneficio de escalabilidad de async . Esto se debe a que IIS puede manejar muchas más solicitudes simultáneas que una sola instancia de SQL Server (u otro RDBMS clásico). Sin embargo, si su back-end es más moderno -un clúster de SQL Server, Azure SQL, NoSQL, etc.- y su back-end puede escalar, y su cuello de botella de escalabilidad es IIS, entonces puede obtener un beneficio de escalabilidad de async .

Tercera pregunta: ¿Cuántas veces puedo usar aguardar palabras clave para consultar la base de datos de forma asincrónica en UN único método de acción?

Tantos como quieras. Sin embargo, tenga en cuenta que muchos ORM tienen una regla de una operación por conexión. En particular, EF solo permite una sola operación por DbContext; esto es cierto si la operación es síncrona o asíncrona.

Además, tenga en cuenta la escalabilidad de su backend de nuevo. Si está accediendo a una instancia única de SQL Server, y su IIS ya es capaz de mantener SQLServer a su capacidad máxima, duplicar o triplicar la presión sobre SQLServer no lo ayudará en absoluto.

Question

Me preocupa el uso de acciones asíncronas en ASP.NET MVC. ¿Cuándo mejora el rendimiento de mis aplicaciones y cuándo no ?

  1. ¿Es bueno usar acción asíncrona en cualquier lugar de ASP.NET MVC?
  2. Con respecto a los métodos disponibles: ¿debo usar palabras clave async / await cuando quiero consultar una base de datos (a través de EF / NHibernate / otro ORM)?
  3. ¿Cuántas veces puedo usar palabras clave de espera para consultar la base de datos de forma asincrónica en un solo método de acción?



Como sabe, MVC admite controladores asíncronos y debe aprovecharlo. En caso de que su Controlador realice una operación larga (puede ser una E / S basada en disco o una llamada de red a otro servicio remoto), si la solicitud se maneja de manera síncrona, el hilo IIS estará ocupado todo el tiempo. Como resultado, el hilo solo está esperando a que se complete la operación larga. Se puede utilizar mejor atendiendo otras solicitudes mientras la operación solicitada en primer lugar está en progreso. Esto ayudará a atender más solicitudes simultáneas. Su servicio web será altamente escalable y no se encontrará fácilmente con el problema C10k . Es una buena idea usar async / await para consultas db. y sí, puede usarlos tantas veces como lo considere apropiado.

Eche un vistazo here para obtener excelentes consejos.




async acciones async ayudan mejor cuando las acciones realizan algunas operaciones de I / O a DB o algunas llamadas enlazadas a la red donde el hilo que procesa la solicitud se detendrá antes de recibir respuesta de la DB o llamada enlazada a la red que acaba de invocar. Lo mejor es que lo use aguarde con ellos y realmente mejorará la capacidad de respuesta de su aplicación (porque menos subprocesos de entrada / salida ASP se estancarán mientras espera la DB o cualquier otra operación como esa). En todas mis aplicaciones cada vez que necesité muchas llamadas a DB, siempre las envolví en un método deseable y las llamé con la palabra clave await.