Server Optimisations Part 2 Hello survivors, last week I published my first Report about how we improved the server performance over the course of January. Today, I'd like to show you some results from the most recent 1.01 Experimental phase. I will also include some other optimisations, which made it to the Experimental build, and discuss future optimisation possibilities. I will begin with the improvements which we've made since the last performance report. Optimised Input System In my last report, I mentioned that the new input system further impaired the server performance - to be more precise, the update of the character controller, which is reading input states, was worse. We improved this controller update and now we are receiving better numbers than with the old input system. Safe system creates a continuous performance degradation Because the server has to simulate a lot of players and AIs, there's a high chance that the server will get into a so called "spiral of death" - this means that if one frame is long enough, another frame can take even more time and this repeats over and over. We decided to add a server config parameter to limit the number of simulated players per frame, which can prevent this behavior. This mechanism can split one long frame into multiple shorter frames, thus the server frame-rate should be much more stable. You can set the number of simulated players per frame using the simulatedPlayersBatch config parameter. This value shouldn't be too low or high, so I recommend to set it around 20. So here are the promised results from the current experimental version. In every row there are average values in one minute intervals (player counts/fps/memory used/active AI): After we saw these nice numbers, we decided to increase maximum players count to 80. We received these statistics: While these results are nice as well, we have had several reports that remote players are sometimes moving in a jittery way. This could be caused by several reasons (one of the reasons could be that the simulatedPlayersBatch parameter was too low - 12 in that case), so we have to investigate the cause and then we will decide, how we can improve it. Future Optimisation Possibilities We would like to focus on optimising the character simulation, especially when it comes to physics and scripts, as these parts are taking the most CPU cycles. In the case of physics, we'd like to reduce the number of the shape casts used for the collision detection. In the case of scripts, we have to make some investigation first and see, what could be optimized, because the scripts are taking around 40 percent of the player's simulation. Another option is to make some logic parallel and move it to other CPU cores. This can be problematic when multiple server instances are running on one machine (which is the case for our official servers), because there won't be free hardware threads, but community servers can benefit from parallel computation a lot, if they're not running multiple server instances. Or we can increase the slots per server instance and reduce the number of instances. So this is a topic which we are still thinking about, meaning this investigation will be probably become a thing in next few weeks. That's all for now, next Server Performance Report will be published before the 1.02 experimental, where I'd like to share the decisions made on these issues.