执行上下文和调度程序-最佳实践，有用的配置和文档 [英] 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.

我想问一下在您日常Dev生活中使用的除了 scala.concurrent.ExecutionContext.Implicits.global 和Akka默认值以外的其他配置，以及它们的优缺点

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
• 默认播放

• 共享

• use instead of scala.concurrent.ExecutionContext.Implicits.global when using Play
• Play default

• shared

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

• 基于配置

• 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

推荐答案

理想情况下，仅使用非阻塞代码，您将只使用框架执行上下文.播放框架或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/documentation/2.5.x/ThreadPools#高度同步

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