Wir machen gute Fortschritte beim Belastungstest und der Skalierung einer Akka-Anwendung, sehen aber, dass scala.concurrent.forkjoin.ForkJoinPool.scan() kommt als der zweithöchste Hotspot in Visualvm um 20% der eigenen Zeit. Die Spalte Eigenzeit (CPU) sagt nur einen Bruchteil davon aus (weniger als 1% des Wertes der Eigenzeitspalte).Akka - während des Belastungstests, forkjoinpool.scan bei 20% der CPU-Zeit
Ich vermute, das bedeutet Blockierung oder Kontextwechsel sind potentiell problematisch, aber ich bin mir nicht sicher - kann jemand Einblick geben? Wenn es Context-Switching ist, denke ich Tuning Dispatcher-Durchsatz auf eine höhere Anzahl kann uns Gewinne, sonst wenn es durch Blockieren verursacht wird, müssen wir den Code mehr lesen.
Jeder Einblick sehr geschätzt.
Ich würde diesen Thread durchlesen, da er einige gute Einblicke in den Grund bietet, warum Sie möglicherweise viel mit dem FJP beschäftigt sind. Möglicherweise haben Sie tatsächlich einen Blockierungscode, der die Vorgänge verlangsamt, was dazu führt, dass die faulen FJP-Threads mehr als erwartet nach Arbeit suchen. https://groups.google.com/forum/m/#!topic/akka-user/6HKTvw4yBnU – cmbaxter
Danke - dieser Thread hat mich davon überzeugt, dass es einige geparkte Threads geben muss - das und die Wanduhrzeit vs tatsächliche CPU verwendet. Dies ist eine hilfreiche Bestätigung +1 – JasonG