I decided to create a stress test. In a mostly blank sim, I created dynamic cubes. Each cube has a script that has a public chat listener, a collision detector, and a timer triggering a rotation feature. The continuous rotation gives a visual indication via "stutters" of imperfect behavior. When you bump into a cube or hit it with another object, it drops to the ground and stops rotating, which makes for nice collision testing.
The most cubes I tried this with is 900. Here's what that looked like:
Loyal troops, tonight we march on the citadel!
The sim ran and everything worked, but it is all too much for my computer because they rotate very slowly. I think this is simply because of the barrage of network messages from the server telling all the cubes to update themselves. My network connection was topping out around 36 Mbps running full tilt in bursts.
When I lowered it to 700 cubes, I could see the rotations, but it was not nearly as smooth as when there were only 100. Walking through the "fields" and bumping them should have caused them to drop like flies. It took about 20 seconds before they stopped rotating and started dropping. It was very choppy motion, though.
At 600, the rotations were smoother. It was still maxing out my bandwidth, apparently, like so:
This time, I waded into the cubes, bumping them, but they didn't drop even after several minutes of waiting. I doubt that's because of network trouble, but I'm not sure what was causing it.
Once I dropped it down to 400 cubes, the rotations were nearing full speed on my computer. Occasionally, they would all stutter at the same time. I did noticed this stuttering occurred every time there was a dip in the bandwidth, which was now down at around 24 Mbps:
They still did not drop when struck, however.
Once I dropped it to 200 cubes, they were rotating closer to full speed (as compared with a single cube in the scene). There were still jitters, again aligned with the network dips:
After wading into the fray, the cubes started to drop after about a minute of waiting. They kept jumping back up and then starting to fall again. It seems that it takes a long time to kill the timer that drives the position updates, even after it has been told to stop and the mass of the cubes is set to 100 (instead of 0). It took about two more minutes before some of them finally dropped and stopped floating and rotating.
One take-away from this observation is that if you want a fast reaction, don't kill the timer. Set a state variable and have your timer-driven updates check that variable and return instantly (or otherwise skip over the updates).
Finally, down at 100 cubes, the dance is vibrant. Here's a video snippet:
There are occasional jitters. They are aligned with the little dips in network bandwidth, but it's harder to see those in the readout:
The cubes drop almost immediately when bumped.
One of my most basic conclusions from this stress test is that bandwidth is the bottleneck. The scene server never crashed. The rate of cube rotation was affected by how many cubes were rotating, which could be a result of the server slowing down under the strain. If so, that actually could be a graceful response by the script engine to server stress. A slower firing rate is better than a crash.
I have a beefy new gaming computer. It never saw more than 70% CPU utilization and its GPU didn't bat an eye, booking at 213 FPS with 100 dynamic objects going and only 43% CPU utilization.