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

Question

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

Execution Context关于在Scala中执行期货的最佳/如何/最佳用途以及如何配置调度程序,存在很多问题.我仍然无法找到更长的列表,其中包含优缺点和配置示例.

我能找到的最好的是Akka文档:http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html和Play Documentation 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))

• 用于测试
• 没有并行性

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

• 使用而不是scala.concurrent.ExecutionContext.Implicits.global使用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

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

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

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

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

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