执行上下文和调度程序 - 最佳实践、有用的配置和文档 [英] Execution Context and Dispatcher - Best practices, useful configurations and Documentation

问题描述

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

There are a lot of questions around what/how/what is the best Execution Context to use to execute futures on in Scala and how to configure the dispatcher. Still I never was able to find a longer list with pros and cons and configuration examples.

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

The best I could find was in the Akka Documentation: http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html and Play Documentation https://www.playframework.com/documentation/2.5.x/ThreadPools.

我想问一下，除了scala.concurrent.ExecutionContext.Implicits.global和Akka默认你在日常Dev生活中使用的还有哪些配置，什么时候使用，优缺点是什么.

I would like to ask what configurations besides the scala.concurrent.ExecutionContext.Implicits.global and Akka defaults you use in your daily Dev lives, when you use them and what are the pros and cons .

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

Here are some of the ones I already have:

• 不确定时使用

• use when unsure

易于使用

可能会耗尽你所有的 CPU

may use up all your CPU

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

• 用于测试
• 没有并行性

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

• 共享

更多信息:https://www.playframework.com/documentation/2.5.x/线程池

• 基于配置

• based on configuration

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

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

推荐答案

理想情况下 仅使用非阻塞代码，您就可以使用框架执行上下文.Play 框架或 Akka 的.

Ideally with only non-blocking code you would just use the frameworks execution context. Play Frameworks or Akka's.

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

But sometimes you have to use blocking API's. In one Play Framework and JDBC project, we followed their recommendation [1] and set the execution context to have 100 threads, and just used the default everywhere. That system was very fast for its usage and needs.

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

In a different Akka project where we had a mix of blocking and non-blocking code we had seperate dispatchers configured for the different features. Like "blocking-dispatcher", "important-feature-dispatcher" and "default-dispatcher". This performed fine, but was more complex than having 1 dispatcher, we had to know/guess/monitor how much each needed. We load tested it and found that at 1 thread it was too slow, if we had 5 threads it was better but after 10 threads it didnt get any faster. So we left it at 10 threads. Eventually we refactored away our blocking code and moved everything to the default.

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

But each use case is different, you need to profile and monitor your system to know whats right for you. If you have all non blocking code its easy, it should be 1 thread per CPU core.

[1] https://www.playframework.com/文档/2.5.x/ThreadPools#高度同步

这篇关于执行上下文和调度程序 - 最佳实践、有用的配置和文档的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！