[C#] 언제 ASP.NET MVC에서 비동기 컨트롤러를 사용해야합니까?

당신은 내 찾을 수 있습니다 도움이 주제에 대한 MSDN 문서를 ; 이 기사에서는 ASP.NET에서 사용 하는 방법 뿐만 아니라 ASP.NET에서 언제 사용 해야하는지 설명하는 많은 공간을 차지했습니다 .asyncasync

ASP.NET MVC에서 비동기 작업을 사용하는 데 약간의 문제가 있습니다. 앱 성능을 향상시킬 때와 그렇지 않을 때

먼저 async/ await가 스레드 를 해제하는 것임을 이해하십시오 . GUI 응용 프로그램에서는 주로 GUI 스레드를 해제 하여 사용자 경험을 향상시키는 것입니다. 서버 응용 프로그램 (ASP.NET MVC 포함)에서 주로 요청 스레드를 해제하는 것입니다. 서버가 확장 할 수 있도록 입니다.

특히, 그것은 하지 않습니다 :

• 개별 요청을 더 빨리 완료하십시오. 실제로, 그들은 완만하게 (완전히 조금씩) 완만하게 될 것이다.
• 를 누르면 발신자 / 브라우저로 돌아갑니다 await. await브라우저가 아닌 ASP.NET 스레드 풀에만 “수율”이됩니다.

첫 번째 질문은 ASP.NET MVC의 모든 곳에서 비동기 작업을 사용하는 것이 좋습니까?

I / O를 수행하는 모든 곳에서 사용하는 것이 좋습니다. 반드시 그런 것은 아닙니다 도움 (아래 참조).

그러나 CPU 바운드 방법에는 사용하지 않습니다 . 때때로 DEVS은의 혜택을받을 수 있다고 생각 async바로 호출하여Task.Run 는 컨트롤러를 하며 이는 끔찍한 아이디어입니다. 이 코드는 다른 스레드를 사용하여 요청 스레드를 해제하므로 아무런 이점이 없습니다 (실제로 추가 스레드 스위치의 페널티를 받고 있습니다)!

데이터베이스를 쿼리 할 때 (EF / NHibernate / other ORM을 통해) async / await 키워드를 사용해야합니까?

사용 가능한 대기 가능한 방법을 사용할 수 있습니다. 현재 대부분의 주요 플레이어는을 지원 async하지만 그렇지 않은 플레이어 도 있습니다. 귀하의 ORM이를 지원하지 않는 경우 async포장하지 마십시오Task.Run 또는 이와 유사한 것을 (위 참조).

내가 ” 사용할 수있다 “고 말했음을 주목하십시오 . 단일 데이터베이스 백엔드로 ASP.NET MVC에 대해 이야기하고 있다면 확장 성 이점을 얻지 못할 것입니다 async. IIS는 단일 SQL Server 인스턴스 (또는 다른 클래식 RDBMS)보다 훨씬 많은 동시 요청을 처리 할 수 ​​있기 때문입니다. 그러나 백엔드는 더 현대적인 경우 – SQL Server 클러스터, 푸른 SQL, NoSQL의 등 -과 백엔드 확장 할 수 있습니다, 그리고 확장 성 병목 현상, IIS입니다 다음 당신이에서 확장 성 혜택을받을 수 있습니다 async.

세 번째 질문-하나의 단일 조치 메소드에서 데이터베이스를 비동기식으로 쿼리하기 위해 대기 키워드를 몇 번 사용할 수 있습니까?

당신이 원하는만큼. 그러나 많은 ORM에는 연결 당 하나의 작업 규칙이 있습니다. 특히 EF는 DbContext 당 단일 작업 만 허용합니다. 작업이 동기식인지 비동기식인지에 관계없이 마찬가지입니다.

또한 백엔드의 확장 성을 다시 염두에 두십시오. 단일 SQL Server 인스턴스를 사용 중이고 IIS가 이미 SQLServer를 전체 용량으로 유지할 수있는 경우 SQLServer에 대한 압력을 두 배로 늘리거나 세 배로 늘려도 전혀 도움이되지 않습니다.

답변

Task task1 = FooAsync(); // launch it, but don't wait for result
Task task2 = BarAsync(); // launch bar; now both foo and bar are running
await Task.WhenAll(task1, task2); // this is better in regard to exception handling
// use task1.Result, task2.Result