播放框架：异步与同步性能

Question

我有以下代码：

  def sync = Action {
      val t0 = System.nanoTime()
      Thread.sleep(100)
      val t1 = System.nanoTime()
      Ok("Elapsed time: " + (t1 - t0) / 1000000.0 + "ms") 
  }

  def async = Action {
    val t0 = System.nanoTime()
    Async { 
          Future{
            Thread.sleep(100)
            val t1 = System.nanoTime()
            Ok("Elapsed time: " + (t1 - t0) / 1000000.0 + "ms") 
            }   
    }
  }

上面的代码之间的区别是：同步将在接收到请求的线程上休眠，而异步将在单独的线程上休眠，以便负责接收请求的线程可以继续接收请求而不会阻塞。 当我分析线程时，发现为异步请求创建的线程数量突然增加。 但是，上述两种方法都具有4000个并发连接20 s斜坡，导致相同的吞吐量和延迟。 我期望异步性能更好。 为什么会这样呢？

Answer 1

简短的答案是这两种方法本质上是相同的。

动作本身总是异步的（请参阅有关处理异步结果的文档 ）。

在这两种情况下， sleep调用都会在操作的线程池中发生（这不是最佳选择）。

如了解游戏线程池中所述 ：

从下至上，播放框架是一个异步Web框架。 流是使用迭代器异步处理的。 由于play-core中的IO永不阻塞，因此Play中的线程池已调整为使用比传统Web框架更少的线程。

因此，如果您打算编写阻塞的IO代码或可能执行大量CPU密集型工作的代码，则需要准确知道哪个线程池正在承担该工作负载，并且需要相应地对其进行调整。

例如，此代码片段使用一个单独的线程池：

Future {
  // Some blocking or expensive code here
}(Contexts.myExecutionContext)

作为其他资源，请参见此答案和本视频 ，以获取有关处理异步操作的更多信息，以及本和本论坛消息，以进行有关该主题的广泛讨论。