scala - Contexto de ejecución y despachador: mejores prácticas, configuraciones útiles y documentación

concurrency playframework

Question

Contexto de ejecución de Scala y despachadores - Listado y comparación: ¿Por qué?

Hay muchas preguntas sobre qué / cómo / cuál es el mejor Execution Context para usar para ejecutar futuros en Scala y cómo configurar el despachador. Aún así, nunca pude encontrar una lista más larga con pros y contras y ejemplos de configuración.

Lo mejor que pude encontrar fue en la documentación de Akka: http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html y Play Documentation https://www.playframework.com/documentation/2.5.x / ThreadPools .

Me gustaría preguntar qué configuraciones además de scala.concurrent.ExecutionContext.Implicits.global y los valores predeterminados de Akka se usan en sus vidas cotidianas de revelador, cuando los usa y cuáles son los pros y los contras.

Estos son algunos de los que ya tengo:

Primera visión general sin terminar

Estándar: scala.concurrent.ExecutionContext.Implicits.global

• usar cuando no está seguro

• Fácil de usar

• compartido por todo

• puede agotar toda tu CPU

• más información: http://www.scala-lang.org/api/2.11.5/index.html#scala.concurrent.ExecutionContext

Prueba - ExecutionContext.fromExecutor(new ForkJoinPool(1))

• usar para probar
• sin paralelismo

EC predeterminado del juego - play.api.libs.concurrent.Execution.Implicits._

• use en lugar de scala.concurrent.ExecutionContext.Implicits.global cuando use Play
• Jugar por defecto

• compartido

• más información: https://www.playframework.com/documentation/2.5.x/ThreadPools

Contexto de ejecución por defecto de Akka

• basado en la configuración

• más información: http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html

Bulkheading

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

Answer 1

Idealmente, con solo código sin bloqueo, simplemente usaría el contexto de ejecución de marcos. Juega Frameworks o Akka''s.

Pero a veces tienes que usar API de bloqueo. En un proyecto de Play Framework y JDBC, seguimos su recomendación [1] y configuramos el contexto de ejecución para tener 100 hilos, y simplemente usamos el predeterminado en todas partes. Ese sistema fue muy rápido para su uso y necesidades.

En un proyecto Akka diferente donde teníamos una combinación de código de bloqueo y no bloqueo, teníamos despachadores separados configurados para las diferentes funciones. Como "bloqueador-despachador", "importante-feature-dispatcher" y "default-dispatcher". Esto funcionó bien, pero era más complejo que tener 1 despachador, teníamos que saber / adivinar / controlar cuánto necesitaban cada uno. Cargamos la prueba y descubrimos que a 1 hilo era demasiado lento, si teníamos 5 hilos, era mejor, pero después de 10 hilos no conseguía nada más rápido. Entonces lo dejamos en 10 hilos. Finalmente, modificamos nuestro código de bloqueo y lo cambiamos todo a los valores predeterminados.

Pero cada caso de uso es diferente, necesita un perfil y monitorear su sistema para saber cuál es el adecuado para usted. Si tiene todo el código que no bloquea es fácil, debe ser de 1 hilo por núcleo de CPU.

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