问题描述
我对在 ASP.NET MVC 中使用异步操作有一些顾虑.它什么时候能提高我的应用程序的性能，什么时候不能?
I have some concerns using async actions in ASP.NET MVC. When does it improve performance of my apps, and when does it not?
- 在 ASP.NET MVC 中随处使用异步操作好吗?
- 关于可等待方法:当我想查询数据库时，我应该使用 async/await 关键字吗(通过 EF/NHibernate/其他 ORM)?
- 在一个单操作方法中，我可以使用await关键字异步查询数据库多少次?
- Is it good to use async action everywhere in ASP.NET MVC?
- Regarding awaitable methods: shall I use async/await keywords when I want to query a database (via EF/NHibernate/other ORM)?
- How many times can I use await keywords to query the database asynchronously in one single action method?
推荐答案
异步操作 方法在操作必须执行多个独立的长时间运行操作时很有用.
Asynchronous action methods are useful when an action must perform several independent long running operations.
AsyncController 类的典型用途是长时间运行的 Web服务电话.
我的数据库调用应该是异步的吗?
Should my database calls be asynchronous ?
与数据库服务器相比，IIS 线程池通常可以处理更多的并发阻塞请求.如果数据库是瓶颈，异步调用不会加快数据库响应.如果没有节流机制，通过使用异步调用有效地将更多工作分派到不堪重负的数据库服务器只会将更多的负担转移到数据库上.如果您的数据库是瓶颈，异步调用就不是灵丹妙药.
The IIS thread pool can often handle many more simultaneous blocking requests than a database server. If the database is the bottleneck, asynchronous calls will not speed up the database response. Without a throttling mechanism, efficiently dispatching more work to an overwhelmed database server by using asynchronous calls merely shifts more of the burden to the database. If your DB is the bottleneck, asynchronous calls won’t be the magic bullet.
源自@PanagiotisKanavos 评论:
Derived from @PanagiotisKanavos comments:
此外，异步并不意味着并行.异步执行释放了一个宝贵的线程池线程阻止外部资源，对于没有复杂性或性能成本.这意味着同一台 IIS 机器可以处理更多并发请求，而不是它会运行得更快.
您还应该考虑阻塞调用以CPU 密集型自旋等待.在压力时期，阻止呼叫将导致延迟升级和应用程序池回收.异步调用避免这种情况
You should also consider that blocking calls start with a CPU-intensive spinwait. During stress times, blocking calls will result in escalating delays and app pool recycling. Asynchronous calls simply avoid this
这篇关于什么时候应该在 ASP.NET MVC 中使用异步控制器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！