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
测试 -
ExecutionContext.fromExecutor(new ForkJoinPool(1))
Play 的默认 EC -
play.api.libs.concurrent.Execution.Implicits._
scala.concurrent.ExecutionContext.Implicits.global
使用 Play 时 Akka 的默认执行上下文
舱壁
ExecutionContext.fromExecutor(new ForkJoinPool(n)) based on an separated dispatcher . Thanks to Sergiy Prydatchenko
最佳答案
理想情况下 仅使用非阻塞代码,您只需使用框架执行上下文。 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
关于scala - 执行上下文和调度程序 - 最佳实践、有用的配置和文档,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34117252/