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

Question

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

关于在Scala中执行期货的最佳Execution Context以及如何配置调度程序，有很多问题。 我仍然无法找到具有优缺点和配置示例的更长列表。

我能找到的最好的是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))

• 用于测试
• no parallelism

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

• 使用Play
时代替scala.concurrent.ExecutionContext.Implicits.global
• 播放默认

• 共享

• 更多信息：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

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

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

在另一个我们有阻塞和非阻塞代码混合的Akka项目中，我们为不同的功能配置了单独的调度程序。喜欢＆＃34;阻止调度员＆＃34;，＆＃34;重要特征调度员＆＃34;和＆＃34;默认调度员＆＃34;。这样做很好，但比1个调度员更复杂，我们必须知道/猜测/监控每个需要多少。我们加载测试它，发现在1个线程它太慢，如果我们有5个线程它更好但是在10个线程之后它没有得到更快。所以我们把它留在了10个线程上。最终我们重构了阻止代码并将所有内容都移到了默认值。

但每个用例都不同，您需要对系统进行分析和监控，以了解适合您的最新情况。如果所有非阻塞代码都很简单，则每个CPU核心应该是1个线程。

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