Ich habe gerade einen JDBC-Verbindungspool mit Akka geschrieben.
Es verwendet einen Akteur, um eine "maxPoolSize" Sammlung von realen Datenbankverbindungen zu halten. Der Anrufer fragt den Pool-Actor nach einer Verbindung und erhält eine Future[Connection] . Der Status der Verbindung wird "busy", bis der Anrufer sie in connection.close an den Pool zurückgibt. Wenn alle Verbindungen besetzt sind, wird die neue eingehende Verbindungsanforderung in eine Warteschlange gestellt (die auch vom Pool-Akteur gehalten wird). Später, wenn eine Verbindung zurückgegeben wird, wird die wartende Anfrage erfüllt.
Die Implementierung dieser Logik ist in akka sehr einfach, nur Dutzende von Codezeilen. Wenn Sie jedoch den BoneCP Multithread-Test verwenden, um die Leistung zu testen (dh der Aufrufer close die Verbindung sofort, wenn Future[Connection] zurückgegeben von getConnection erfüllt ist.Der Benchmark traversed all die close Anfrage und Await für das Ergebnis Future ), Ich fand, dass die Akka-Version ist langsamer als viele andere Connection Pool-Implementierungen wie tomcat-jdbc , BoneCP oder sogar commons DBCP.
Was ich für das Tuning versucht habe:
aber sah keine merkliche Verbesserung.
Meine Frage ist:
Um Frage Nr. 1 zu beantworten, ist dies kein Anwendungsfall, bei dem Akka in der Geschwindigkeit überragend ist. Sie haben im Grunde ein Problem gelöst, das normalerweise mit einer gleichzeitigen Datenstruktur gelöst wird, die für mehrere Leser und Schreiber optimiert und durch einen einzigen Akteur serialisiert ist.
Ein anderer Ansatz besteht darin, einen Router zu erstellen, der jeweils mehrere Slave-Actors hervorbringt eine einzelne Verbindung darstellen.
Aber seien Sie sich bewusst, dass es mögliche Rassenbedingungen geben könnte.
Auch, welche Version von Scala und Akka verwenden Sie?
Tags und Links scala performance akka