scala - 执行上下文和调度程序 - 最佳实践、有用的配置和文档

Question

Scala 执行上下文和调度程序 - 列表和比较:为什么？

关于什么/如何/什么是最好的有很多问题Execution Context用于在 Scala 中执行 future 以及如何配置调度程序。
我仍然无法找到更长的列表，其中包含优缺点和配置示例。

我能找到的最好的是 Akka 文档:http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html和 Play 文档https://www.playframework.com/documentation/2.5.x/ThreadPools .

我想问一下除了scala.concurrent.ExecutionContext.Implicits.global还有什么配置并且 Akka 默认您在日常开发生活中使用，何时使用它们以及优缺点是什么。

以下是我已经拥有的一些:

第一个未完成的概述

标准:scala.concurrent.ExecutionContext.Implicits.global

不确定时使用

易于使用

共享一切

可能会耗尽你所有的 CPU

更多信息:http://www.scala-lang.org/api/2.11.5/index.html#scala.concurrent.ExecutionContext

测试 - ExecutionContext.fromExecutor(new ForkJoinPool(1))

用于测试

无并行性

Play 的默认 EC - play.api.libs.concurrent.Execution.Implicits._

使用代替 scala.concurrent.ExecutionContext.Implicits.global使用 Play 时

Play 默认

共享

更多信息:https://www.playframework.com/documentation/2.5.x/ThreadPools

Akka 的默认执行上下文

基于配置

更多信息:http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html

舱壁

ExecutionContext.fromExecutor(new ForkJoinPool(n)) based on an separated dispatcher . Thanks to Sergiy Prydatchenko

Answer 1

理想情况下 仅使用非阻塞代码，您只需使用框架执行上下文。 Play Frameworks 或 Akka 的。

但有时您必须使用阻塞 API。在一个 Play Framework 和 JDBC 项目中，我们遵循了他们的建议 [1]，将执行上下文设置为 100 个线程，并且在任何地方都使用默认值。该系统的使用和需求非常快。

在另一个 Akka 项目中，我们混合了阻塞和非阻塞代码，我们为不同的功能配置了单独的调度程序。像“blocking-dispatcher”、“important-feature-dispatcher”和“default-dispatcher”。这表现良好，但比拥有 1 个调度员更复杂，我们必须知道/猜测/监控每个需要多少。我们对其进行了负载测试，发现在 1 个线程时它太慢了，如果我们有 5 个线程它会更好，但是在 10 个线程之后它并没有变得更快。所以我们将其保留为 10 个线程。最终我们重构了我们的阻塞代码并将所有内容移到默认值。

但是每个用例都是不同的，您需要分析和监控您的系统以了解什么适合您。如果您拥有所有非阻塞代码很容易，那么每个 CPU 内核应该是 1 个线程。

[1] https://www.playframework.com/documentation/2.5.x/ThreadPools#Highly-synchronous