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

Question

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

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

我们试图找到解决方案，在大多数帖子中我们发现我们应该通过 工作线程的 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. 为什么在上一个例子中，在 await 任务中设置 "HttpContext.Current"， 导致请求返回与同步结果相同的不良性能结果？

2. 有没有另一种方法可以在调用的内部任务中使用 "HttpContext.Current" - "ExecuteServerLogics"， 并且在所有也调用 "HttpContext.Current" 的静态类中？ 我在某种程度上做错了整个设计吗？

谢谢！

Answer 1

从头开始：

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

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

继续：

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

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

特别是，Task.Run 将抵消async 的所有性能优势，然后进一步降低性能。我相信您测量的性能改进是巧合。

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

那些帖子是错误的。恕我直言。您最终会使用后台线程中的 HttpContext 对象，而该对象专门设计为只能从请求线程访问。

我是否在某种程度上做错了整个设计？

我建议您退后一步，从大局考虑。当一个请求进来时，它有一定的工作要做。该工作是同步完成还是异步完成对客户来说并不重要；这两种方法所花费的时间大致相同。

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

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

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

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

Answer 2

如果您的任务在您的 ApiController 派生类中，您可以使用：

var ctx = this.Request.Properties["MS_HttpContext"] as System.Web.HttpContextWrapper;

这将为您提供一个包含所有常用属性的 HttpContext 包装器。

Answer 3

Amir 我认为您正在寻找类似下面的内容。我一直在处理同样的问题，试图优化一系列调用。它需要一直是异步的，这意味着您的 ExecuteServerLogics() 需要是异步的，并且您还必须将包含的 lamda 标记为异步。

我相信遵循这种模式可能会消除大部分性能问题。很好地通过这样的方式传递上下文。

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

      object response = await Task<object>.Run(async () =>
      {
           // Set the context of the current task :
           HttpContext.Current = currentContext ;

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

      return response;
}