It is important to remember that the server is simulating for multiple and perhaps many people at once.
One of the implications of this, is that projects and builds that may have worked just fine when they were the only thing loaded into the world in your offline game are simply not a good or feasible idea in the multiplayer environment. Daisy-chaining subgrids is one common practice that while somewhat possible offline, gets much more risky in our server environment.
When the game is at heavy load, things that would normally get full and accurate calculations start to use rounding out of necessity.
These rounding errors, when present in a sensitive simulation such as a precarious drilling array of multiple rotors and pistons, can lead to the game believing something is somewhere it shouldn't be, and explosively “correcting” that issue
Every grid in the game, no matter how small or simple, is having physics and other calculations done for it every tick. Even if it is a small grid, 2000 PCU ship sitting completely still and idle, it is taking processing time from the server.
For Example: Even a small collection of 3 or more grids can start to create a big impact on the server as a whole, bringing sim down by 10-30% per instance of clustering.
It is very, very important to keep any and all grids that are not currently, actively needed in that very moment at least 1.5km away from logged in players, and any grids not being used within the next hour at least 5km away from logged in players.
Alternatively, storing grids in your hangar would satisfy this requirement as well.
There is no hard limit that can be applied to number of grids clustered, we have seen players with clusters of 6 have a smaller impact on server performance than a player with a cluster of 3. If staff identifies a cluster a potential source of impact to simspeed, you may be asked to spread the grids out.
While converting a Large Grid to Station, or using landing gear or connectors to dock ships together reduces these calculations somewhat, it is not enough of a reduction in calculations to prevent impacts to server performance. It only takes about 30 seconds to fly 5km in a suit to your grid.
These blocks in vanilla are the only way to do anything other than a straight connection or 90 degree turn, as well as providing attachment on all faces.
So, many engineers get in the habit of using a lot of them, or even using them exclusively.
You will find many workshop designs packed with conveyor junctions.
Unfortunately due to the way Keen decided to compute connections between blocks through conveyors, every single face of every single Junction is being checked on every possible path every single tick. It is important to minimize the use of Junctions, using them only when absolutely necessary in your designs
We have 2 mods that add more conveyor options with different amount of forks to be used instead of junctions.
It is best practice to use the minimum number of conveyor faces as possible.
Ship printers being almost essential to space engineers also are notoriously bad on sim speed especially when done inefficiently. A few tips to follow when building printers
In this category of creations and behaviors we find all sorts of neat ideas that, similar to Clang Contraptions, are unfortunately just not a prudent choice in the server environment.
This includes but is not limited to things like “Clang Drives” that leverage merge blocks to generate “thrust,”; Mass-Shifting drives; Rotor-displacement-cannons; and all similar practices.
Please lock rotors when not in use or not needed to improve server performance.
If you are about to attempt something that might fall into this category, stop, think, and please ask a member of staff about what you intend to do before you start.
To note, Gravity Drives are acceptable for use as long as they are well-made. As far as server performance, use less gravity generators and more artificial mass.