Jak duża jest pula wątków Scala dla przyszłości?Jak skonfigurować dobrze dopasowaną pulę wątków dla kontraktów terminowych?
Aplikacja My Scala zarabia miliony future {} s i zastanawiam się, czy jest coś, co mogę zrobić, aby je zoptymalizować, konfigurując pulę wątków.
Dziękuję.
Możesz określić własny Kontekst Wykonawczy, w którym będą działać twoje futures, zamiast importować globalny niejawny 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) {}
}
Wielką odpowiedź możesz nieco zredukować bohaterem przy użyciu metod pomocniczych w ExecutionContext, które pozwalają na tworzenie instancji bezpośrednio z danego Executora. Np. niejawne val ec = ExecutionContext.fromExecutor (Executors.newFixedThreadPool (10)) – monkjack
To wszystko jest miłe, ale czy istnieje realna granica w wątkach na implicits.global? Jeśli tak, to jest konfigurowalne jak akka przez application.conf? – Nick
@Nick yes, implicits.global to tylko 1 wątek na rdzeń procesora. Optymalny dla zadań związanych z cpu. Ale dla klasycznego blokowania IO (np. Jdbc) jest to katastrofa wydajności. –
Ta odpowiedź pochodzi z monkjack, komentarz z zaakceptowanej odpowiedzi. Można jednak tęsknić za tą wspaniałą odpowiedzią, więc przesyłam ją tutaj.
implicit val ec = ExecutionContext.fromExecutor(Executors.newFixedThreadPool(10))
Jeśli wystarczy zmienić liczbę pul wątków, wystarczy użyć globalnego executora i przekazać następujące właściwości systemu.
-Dscala.concurrent.context.numThreads=8 -Dscala.concurrent.context.maxThreads=8
to bardziej eleganckie rozwiązanie –
najlepszym sposobem określenia puli wątków kontraktami Scala:
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 używa własne połączenie i puli wątków więc dlaczego musimy zapewnić niejawny executioncontext do wycieku, gdy zarządza własnej puli wątków –