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

我正在使用“Web Api 休息服务的 Postasync 方法：

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

      return response;
}

上面的代码运行良好，但在一些客户的调用中，我们遇到了性能问题。

阅读这里的一些文章后，我注意到我们的 webApi 休息服务， 并没有真正异步地处理传入的网络请求， 因为我们忘记使用异步/等待模式 :

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

      return response;
}

经过这次修复后，我们注意到性能得到了改善， 但我们发现了另一个批评者的问题： 当访问时HttpContext.Current- 它返回空引用：

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;
}

我们试图找到一个解决方案，在大多数帖子中我们发现我们应该通过 工作线程的HttpContext引用执行服务器逻辑的内部任务。 该解决方案的问题在于服务器的逻辑方法使用许多静态类，这些静态类使用“HttpContext.Current”例如 -

1. 记录员打电话。
2. 检索 user.identity 的静态安全类
3. 检索传入请求会话数据等的静态安全类。

因此，通过“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.为什么在最后一个例子中，设置“HttpContext.Current”在等待任务中， 导致请求返回相同的不良性能结果，类似于同步结果？

2.我们还有其他方法可以使用吗“HttpContext.Current”在调用“ExecuteServerLogics”的内部任务内， 以及所有也调用的静态类“HttpContext.Current”？ 我整个设计是不是错了？

Thanks!

从一开始就：

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

不要忽略编译器警告；编译器将为该方法生成一个警告，明确指出它将同步运行。

继续：

在一些客户的通话中，我们遇到了性能问题。

服务器上的异步代码将not单独的单个调用速度更快。它只会帮助你scale你的服务器。

尤其，Task.Run将抵消所有的性能优势async然后稍微降低性能。我相信您测量到的性能改进纯属巧合。

在大多数帖子中，我们发现我们应该将工作线程的 HttpContext 引用传递到执行服务器逻辑的内部任务中。

这些帖子都是错误的。恕我直言。你最终会使用HttpContext来自后台线程的对象，当该对象专门设计为只能从请求线程访问时。

我整个设计是不是错了？

我确实建议您退后一步，考虑一下大局。当请求到来时，它有一定量的工作要做。该工作是同步完成还是异步完成对于客户端来说并不重要；两种方法将花费大约相同的时间。

如果您需要返回early对于客户来说，那么您将需要一个完全不同的架构。通常的方法是将工作排队到可靠的队列（例如 Azure 队列），拥有单独的后端（例如 Azure WebRole），并在工作完成时主动通知客户端（例如 SignalR）。

这并不是说async不过是没用的。如果ExecuteServerLogics是一个 I/O 绑定方法，那么它应该是异步的而不是阻塞的，然后你可以使用异步方法，如下所示：

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

这将使您的服务器总体上更具响应性和可扩展性（即，不会被许多请求淹没）。