csgbn

Full logs of this event: https://fhlsdhfkjshfsf6867f87dsfidsf7sd6fds.s3.us-west-1.amazonaws.com/distributor-gridlog.log https://fhlsdhfkjshfsf6867f87dsfidsf7sd6fds.s3.us-west-1.amazonaws.com/event-bus-gridlog.log https://fhlsdhfkjshfsf6867f87dsfidsf7sd6fds.s3.us-west-1.amazonaws.com/router-gridlog.log https://fhlsdhfkjshfsf6867f87dsfidsf7sd6fds.s3.us-west-1.amazonaws.com/sessionqueue-gridlog.log https://fhlsdhfkjshfsf6867f87dsfidsf7sd6fds.s3.us-west-1.amazonaws.com/sessions-gridlog.log

The grid is deployed distributed (hub and nodes on separate vm's): ``` (sudo -u ubuntu /usr/bin/java -jar /home/ubuntu/selenium-server-4.1.2.jar event-bus --log "/home/ubuntu/event-bus-gridlog.log" --log-level "FINE" --allow-cors true --tracing false --max-threads 6096 >/home/ubuntu/event-bus-stdout.log...

Correction, the hub VM for this test was a 4CPU/8GB and the large max-threads 6096 came from our V3 grid deployment of (jettyMaxThreads). We have though experimented with different max-threads...

Same here, in v3 there was a section in the proxy, before session and after session that was maintained throughout the iterations and could be used to prep the node...