Performance issue: playing through adventure service is much heavier on CPU than local

[ewjmulder]

LOCAL FILE SOURCE

idle: 0%
0 scenarios: 10%
1 scenarios: 40%
2 scenarios: 70%
3 scenarios: 70%
4 scenarios: 70%
6 scenarios: 80%

[ewjmulder]

So local source file playing (triggered over the network with TestNetworkClientSparrenBurcht) first increases linear, but beyond 2 scenario's is quite stable in CPU usage. Probably because increased use of MixerStep algorithm code is the most pressing on CPU, while the other parts (reading, writing) of the scenario actions are quite low in CPU. This is actually a good sign: the main algorithm has a relatively high cost, but scaling up in scenario's is not that expensive.

[ewjmulder]

URL NETWORK SOURCE - WITH WAIT FOR

idle: 0%
0 scenarios: 10%
1 scenarios: 120%
2 scenarios: 240%
3 scenarios: 340% - But quickly hickups and total stop

URL NETWORK SOURCE - NO WAIT FOR

idle: 0%
0 scenarios: 10%
1 scenarios: 45%
2 scenarios: 70% - But still hickups and total stop!
3 scenarios: 70% - But quickly hickups and total stop

[ewjmulder]

So WAIT_FOR makes a dramatic difference in CPU usage! That needs to be researched and fixed.
On the other hand, there seems to be a second issue causing hickups and total stop when using multiple network resources in parallel.

[ewjmulder]

Bottleneck in the Wait for implementation seems to be the Thread.sleep, although from documentation that should not be the case. When replaced with wait() and notifyAll() on ActiveScenario's CPU goes down a lot again. It this a 'bug' in Pine64 + Java + Thread sleep + CPU usage counting? Or is it a 'real thing' in any JVM happening with this code?

[ewjmulder]

The 'normal step thread' also uses Thread.sleep and that does not cause a high CPU peak. Also a small test running just Thread.sleep in a main does not cause any CPU. So still unclear what is really causing this weird CPU spike. Maybe we are inside some kind of lock or Thread.sleep context is heavy on scheduler / checker?