Quanto è grande il pool di thread di Scala per i futures?Come configurare un pool di thread ottimizzato per i future?
La mia applicazione Scala fa molti milioni di future {} s e mi chiedo se c'è qualcosa che posso fare per ottimizzarli configurando un pool di thread.
Grazie.
È possibile specificare il proprio ExecutionContext in cui verrà eseguito il futuro, invece di importare l'implicito implicito globale di ExecutionContext.
import java.util.concurrent.Executors
import scala.concurrent._
implicit val ec = new ExecutionContext {
val threadPool = Executors.newFixedThreadPool(1000);
def execute(runnable: Runnable) {
threadPool.submit(runnable)
}
def reportFailure(t: Throwable) {}
}
Grande risposta, è possibile ridurre un po 'lo standard utilizzando i metodi helper su ExecutionContext che consentono di creare un'istanza direttamente da un determinato Executor. Es. implicit val ec = ExecutionContext.fromExecutor (Executors.newFixedThreadPool (10)) – monkjack
Concesso che tutto ciò sia bello, ma esiste un limite reale nei thread su implicits.global? Se è così configurabile come akka tramite application.conf? – Nick
@Nick yes, implicits.global è solo 1 thread per core della CPU. Ottimale per le attività associate alla cpu. Ma per il classico I/O di blocco (ad esempio jdbc) è un disastro di prestazioni. –
Questa risposta proviene da monkjack, un commento dalla risposta accettata. Tuttavia, si può perdere questa grande risposta, quindi sto ripubblicando qui.
implicit val ec = ExecutionContext.fromExecutor(Executors.newFixedThreadPool(10))
Se avete solo bisogno di cambiare il numero di pool di thread, basta usare l'esecutore globale e superare le seguenti proprietà di sistema.
-Dscala.concurrent.context.numThreads=8 -Dscala.concurrent.context.maxThreads=8
questa è una soluzione più elegante –
modo migliore per specificare di thread in futures Scala: connessione
implicit val ec = new ExecutionContext {
val threadPool = Executors.newFixedThreadPool(conf.getInt("5"));
override def reportFailure(cause: Throwable): Unit = {};
override def execute(runnable: Runnable): Unit = threadPool.submit(runnable);
def shutdown() = threadPool.shutdown();
}
Slick 3.0 usi proprio e di thread così perché abbiamo bisogno di fornire ExecutionContext implicito a chiazza di petrolio quando riesce proprio pool di thread –