【问题标题】:Server-side async best practices服务器端异步最佳实践
【发布时间】:2018-03-06 16:22:58
【问题描述】:

NewbieQ:想知道 C# async / await

我有一个服务器端 ajax 请求处理程序,现在完成时间过长导致超时错误。

处理程序调用一个方法:

public bool Run(Guid jobId) // returns true if successful in running jobId

作业运行一系列操作,这些操作交替地受 IO 限制,然后是 CPU 限制,以防万一。

理想情况下,我希望能够启动 Run,然后不时查询 run 的状态,然后获取结果(Run 返回的 bool)。

编写服务器端代码执行此操作时的最佳做法是什么?

我可以像这样写一个包装器吗?

public async Task<bool> RunAsync(Guid jobId) {...}

如果是这样,那如何调用非异步运行?

或者我需要完全重写 Run 方法吗?最终,我从 ajax 请求处理程序调用它,所以我需要返回作业结果,或者,我可以更改请求,以便我启动作业,然后不时查询具有 {bool resultReady,布尔? result} 或类似的结构。

【问题讨论】:

  • 如果您有多个可以并行运行的进程,async/await 会很有帮助。如果这是一个正在运行并超时的单个进程,那么 async/await 将无济于事。听起来您应该有另一个进程,例如控制台应用程序,它会收到通知以开始执行此工作。控制台应用程序不会像 Web 请求那样超时,但您必须轮询结果。或者,您可以考虑增加 IIS/ASP.NET 超时之前的时间量。stackoverflow.com/questions/2414441/…
  • 明白了,但是这是在一个 Web 服务上运行的,那里有其他用户有其他事情要做,事实上,即使是请求这个任务的用户也可能希望在他们等待的时候做其他事情结果。我真正担心的是 Web 服务本身在等待任务作为同步任务完成时超时。
  • @ps2goat 这不是真的。 await 对于管理异步操作很有用。这些操作是否并行工作并不重要。
  • @Servy- 我可能措辞不正确。我的意思是,如果在超时的过程中有一组同步步骤,异步等待将没有优势。例如,单个过程具有步骤 1 -> 步骤 2 -> 步骤 n。如果每个都必须在下一个开始之前完成,会有优势吗?
  • 如果步骤是 IO 绑定的,那么在 .Net 之外运行 IO 操作时线程将是空闲的

标签: c# iis async-await


【解决方案1】:

您可以查看hangfire,或者signalR,长时间运行的进程可能会发生在事件处理程序中以通知客户端。

【讨论】:

    【解决方案2】:

    您真正想要的不是用一种简单、单一的方法就能完成的事情。您确实需要一个队列系统,您可以在其中检查队列中给定消息的状态。本质上,您将拥有一个将某些内容放入队列(例如 MSMQ)的方法和另一个返回给定jobId 状态的方法。

    【讨论】:

      猜你喜欢
      • 2010-12-21
      • 2011-01-24
      • 2012-04-12
      • 2020-08-15
      • 1970-01-01
      • 2010-10-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多