Hi, everyone!
Since I have basic knowledge about game networking, I was a bit confused with Rust's performance with different server.tickrate and fps.limit numbers.
I've tested this both on local machine and VDS, and got same results:
Server tickrate (which is supposed to determine, how many simulations would be performed in one second), has ABSOLUTELY NO IMPACT to gameplay nor to CPU load percentage.
However Server FPS (which as far as I know needed to minimize tickrate deviations) has direct impact both on performance and gameplay (if it's below ~25 you start experience movement stutters, physics calculation delays, impossible to reload, ammo gets back to your gun after you have already shot it etc.) Btw it seems like all the shots are still registered (like if it was client-side hit validation...).
Could someone experienced with Rust networking explain, which point I'm getting wrong?

Hi!
server.tickrate is using when a server startup, so changing this while the server running doesn't affect to the performance.
This value mainly used to update RCON and to receive any network packets which the server have to receive.

The fps.limit setting does not give your server more FPS, it simply limits it to prevent wasted system resources. Setting it above 256 is generally wasteful, with most game servers running at 60-256.

I used to restart server with bat/shell script changes to tickrate, but I don't think I've noticed any difference.
So, are weapon-related functions like ballistics, spears/axes trajectory are calculated on client?

I REALLY don't understand the reason You posted this...
And I don't understand why You've changed thread title, since its not the question about difference between FPS and tickrate. (Everyone can google it in 1 second)

Misread what you posted when I was mobile, sorry.

It's ok =)
Also do You (or anyone) knows if there any graph to see packets per second (uploaded and received) in Rust?

Not that I know of natively. I'm sure something could be written to output that sort of information. There is a basic bytes up/down stat on our custom console output though.