Você pode encontrar meu artigo do MSDN sobre o assunto útil ; Ocupei muito espaço nesse artigo, descrevendo quando você deveria usar async
no ASP.NET, não apenas como usá async
-lo.
Tenho algumas preocupações ao usar ações assíncronas no ASP.NET MVC. Quando melhora o desempenho dos meus aplicativos e quando - não.
Primeiro, entenda que async
/ await
é sobre liberar threads . Nos aplicativos da GUI, trata-se principalmente de liberar o encadeamento da GUI para que a experiência do usuário seja melhor. Nos aplicativos de servidor (incluindo o ASP.NET MVC), trata-se principalmente de liberar o encadeamento de solicitação para que o servidor possa ser dimensionado.
Em particular, não irá:
- Faça suas solicitações individuais serem concluídas mais rapidamente. Na verdade, eles serão concluídos (um pouquinho) mais devagar.
- Retorne ao chamador / navegador quando você pressionar um
await
. await
somente "produz" para o pool de threads do ASP.NET, não para o navegador.
A primeira pergunta é - é bom usar ação assíncrona em qualquer lugar no ASP.NET MVC?
Eu diria que é bom usá-lo em qualquer lugar em que você esteja fazendo E / S. Porém, pode não ser necessariamente benéfico (veja abaixo).
No entanto, é ruim usá-lo para métodos ligados à CPU. Às vezes, os desenvolvedores acham que podem obter os benefícios async
apenas chamando Task.Run
seus controladores, e essa é uma ideia horrível. Como esse código acaba liberando o encadeamento de solicitação, retomando outro encadeamento, não há benefício algum (e, de fato, eles estão tendo a penalidade de alternar os encadeamentos extras)!
Devo usar palavras-chave assíncronas / aguardar quando quiser consultar o banco de dados (via EF / NHibernate / outro ORM)?
Você pode usar qualquer método que esteja disponível. No momento, a maioria dos principais players suporta async
, mas há alguns que não. Se o seu ORM não suportar async
, não tente envolvê-lo Task.Run
ou algo assim (veja acima).
Note que eu disse "você poderia usar". Se você está falando sobre o ASP.NET MVC com um único back-end de banco de dados, você (quase certamente) não obterá nenhum benefício de escalabilidade async
. Isso ocorre porque o IIS pode manipular solicitações muito mais simultâneas do que uma única instância do SQL server (ou outro RDBMS clássico). No entanto, se o seu back-end é mais moderno - um cluster de servidor SQL, SQL Azure, NoSQL, etc - e seu backend pode escalar, e o gargalo escalabilidade é IIS, em seguida, você pode obter um benefício escalabilidade de async
.
Terceira pergunta - Quantas vezes posso usar as palavras-chave aguardar para consultar o banco de dados de forma assíncrona em UM método de ação única?
Quantas você quiser. No entanto, observe que muitos ORMs têm uma regra de uma operação por conexão. Em particular, o EF permite apenas uma única operação por DbContext; isso é verdade se a operação é síncrona ou assíncrona.
Além disso, lembre-se da escalabilidade do seu back-end novamente. Se você está acessando uma única instância do SQL Server e seu IIS já é capaz de manter o SQLServer em sua capacidade total, dobrar ou triplicar a pressão no SQLServer não ajudará em nada.