asp.net – Web API服务 – 如何在异步任务中使用“HttpContext.Current”

我正在使用webApi休息服务的“Post”异步方法：

public async Task<object> Post([FromBody]string data)
{
      object response = ExecuteServerLogics(data);

      return response;
}

上面的代码工作得很好,但在一些客户的电话中,我们遇到了性能问题.

在这里阅读了一些文章后,我注意到我们的webApi休息服务,
并没有真正与其传入的Web请求异步工作,
因为我们忘了使用async / await模式：

public async Task<object> Post([FromBody]string data)
{
      object response = await Task<object>.Run( () =>
      {
           return ExecuteServerLogics(data);
      });

      return response;
}

在此修复后,我们注意到性能变得更好,
但我们发现了另一个批评问题：
访问HttpContext.Current时 – 它返回Null引用：

public async Task<object> Post([FromBody]string data)
{
      object response = await Task<object>.Run( () =>
      {
           var currentContext = HttpContext.Current; // Returns Null!
           return ExecuteServerLogics(data);
      });

      return response;
}

我们试图找到一个解决方案,在大多数帖子中我们发现我们应该通过
worker thread的HttpContext引用到执行服务器逻辑的内部Task.
这个解决方案的问题是服务器的逻辑方法,使用许多使用的静态类
“HttpContext.Current”如 –

>记录器调用.
>检索user.identity的静态安全性类
>静态安全类,用于检索传入请求的会话数据等.

因此,传递工作线程的“HttpContext.Current”引用将无法解决它.

当我们尝试下一个解决方案时：

public async Task<object> Post([FromBody]string data)
    {
          // Save worker context:
          var currentContext = HttpContext.Current; 

          object response = await Task<object>.Run( () =>
          {
               // Set the context of the current task :
               HttpContext.Current = currentContext ; // Causes the calls not to work asynchronously for some reason!

               // Executes logics for current request:
               return ExecuteServerLogics(data);
          });

          return response;
    }

出于某种原因,我们注意到性能再次恶化,就像它再次同步恢复工作一样.

我们的问题是：

1.为什么在最后一个例子中,在await任务中设置“HttpContext.Current”,
导致请求返回与同步结果类似的相同不良性能结果？

2.还有另一种方法我们可以在调用的内部任务中使用“HttpContext.Current” – “ExecuteServerLogics”,
并且在所有静态类中也称为“HttpContext.Current”？
我以某种方式做错了整个设计吗？

谢谢！

解决方法

从最开始：

public async Task<object> Post([FromBody]string data)
{
  object response = ExecuteServerLogics(data);
  return response;
}

不要忽略编译器警告;编译器将为此方法生成警告,该警告明确指出它将同步运行.

继续：

in some of the client’s calls,we experienced performance issues.

对于单独的单个调用,服务器上的异步代码将不会更快.它只能帮助您扩展服务器.

特别是,Task.Run将否定异步的所有性能优势,然后将性能降低一点.我相信你所测量的性能改善是巧合的.

in most posts we found that we should pass the worker thread’s HttpContext reference into the inner Task that executes the server logics.

这些帖子是错误的.恕我直言.当该对象专门设计为仅从请求线程访问时,您最终会使用后台线程中的HttpContext对象.

am I doing the entire design wrong somehow?

我建议你退后一步,考虑一下大局.当请求进入时,它有一定的工作量.这项工作是同步还是异步完成对客户来说无关紧要;两种方法都需要大约相同的时间.

如果您需要尽早返回客户端,那么您将需要一个完全不同的架构.通常的方法是将工作排队到可靠的队列(例如,Azure队列),具有单独的后端(例如,Azure Webrole),并且在工作完成时主动通知客户端(例如,SignalR).

但这并不是说async是无用的.如果ExecuteServerLogics是一个I / O绑定方法,那么它应该是异步而不是阻塞,然后您可以使用异步方法：

public async Task<object> Post([FromBody]string data)
{
  object response = await ExecuteServerLogicsAsync(data);
  return response;
}

这将使您的服务器整体上更具响应性和可扩展性(即,不会被许多请求所淹没).

asp.net – Web API服务 – 如何在异步任务中使用“HttpContext.Current”

解决方法

相关文章