Our game is nearing release and we did a stress test that resulted in some critical issues with server authority. It is a shooter fps.
The game feels nearly perfect with 1-6ish players but as soon as we get to a full 12 player lobby things started feeling off. For example: even on an empty baseplate a full active 12 player server with server authority enabled would likely be roughly ~60 - 70 recv, which is a bother since that’s essentially the ‘baseline’ we have to assume and work with. When we tested with 12 players on the real game we were hitting 150 plus and people were starting to complain about hitches and shots not hitting and various other things that only show up in stress test.
Update
we also just ran a test just turning server authority off and our receive rate dropped nearly 100. So it’s 100% causing some of the performance issues we are seeing with more players.
Update 2
I assume part of the culprit is NextGenerationReplication cause even with server authority off and this on Receive Rates spike
Expected behavior
We expect Server Authority not to increase our receive rate / cause perf issues. If anything we’d assume it helps in those areas.
Hey! Thank you - here ya go. Added context. We captured this microprofile when the game had 130 receive rate and one player and 11 bots. The equivalent with Server Auth disabled was 25 receive rate.
Hey! Can you help elaborate the specific blockers?
Is it that the Bandwidth is too high, or there are performance spikes as well?
You are correct that NextGenerationReplication, which supports Server Authority increases bandwidth costs. It increases how often we replicate/synchronize physics to match properties, which is what allows the semi-determinism needed for Server Authority. I think physics replication jumps from 15Hz to 60Hz, which would lead to about a 4x increase in bandwidth. Is this scale of increase an issue for your game?
Server Authority also enables “Input Replication” which may increase Client → Server bandwidth if you have a lot of Input Actions, since they are duplicated to avoid drops.
Any more details about your goals and why higher bandwidth is concerning.
The main concern is the bandwidth rather than a consistent CPU or rendering performance spike.
With a full server of around 12 active players, our receive rate typically sits near 100 KB/s and can fluctuate or spike above 200 KB/s. That is well beyond the commonly referenced 50 KB/s soft limit, and a large portion of that bandwidth appears to come directly from NextGenerationReplication and Server Authority rather than systems we can meaningfully optimize ourselves.
During full-server stress tests, these higher receive rates have also coincided with player-reported hitches, increased latency, and shots occasionally not registering as expected. When we disable Server Authority, our receive rate drops by nearly 100 KB/s in the same environment, so the additional replication cost appears to be a significant contributor.
The 4x increase from physics replication moving from 15 Hz to 60 Hz makes sense, but it leaves us with very little networking headroom for the rest of the game. Our concern is that whenever we encounter latency or bandwidth-related issues, there may be limited action we can take on our side because so much of the baseline cost is inherent to enabling Server Authority.
We have seen other FPS games operate around 100 KB/s receive rates—but it does reduce our flexibility and makes scaling to full 12-player servers more difficult. We are strongly committed to using Server Authority, so our main goals are to understand:
Whether the 50 KB/s receive-rate soft limit should still be treated as applicable when using NextGenerationReplication and Server Authority.
Whether receive rates of 100–200+ KB/s are expected for a 12-player physics-heavy game.
Whether there are any settings, profiling tools, or recommended patterns available to reduce the replication overhead.
Whether Roblox is actively working on reducing the bandwidth cost of Server Authority over time.
We would be happy to provide additional captures or run more controlled A/B tests if that would help isolate the issue. We ran a test without server auth with the same group of players today and it went way better. So as of now we can unblock by just not using it but we see a ton of value if we can get server auth working for our game. We would be one of the only FPS shooters utilizing it (at least for now).
I may be ignorant of the resources that show the soft limit of 50KB/s, are you able to share those with me?
For context, the old Physics Sender had about a 50 KB/s limit that if you started hitting, it would start throttling and reduce the frequency of updates on parts to fit things into this limit.
With Workspace.NextGenerationReplication, physics updates and property updates are all put on the same bandwidth limit (much higher than 50KB/s), and also on the same synchronized timeline (it’s what allows Server Authority to correct things properly).
In theory you shouldn’t need to worry about going over 50KB/s anymore, but you were saying you were seeing hitches? Could you share this? Can I join a playtest sometime?
Thanks—that clarification is very helpful. It sounds like our concern around the 50 KB/s soft limit was based on guidance related to the older Physics Sender. We have always aimed to stay at or around that limit on games so that’s good to know.
That said, we still believe Server Authority is contributing to the issues we experienced, even if the raw receive rate itself is not inherently a problem.
In our earlier full 12-player tests with Server Authority enabled, multiple players reported noticeable hitches, inconsistent responsiveness, and shots occasionally not registering as expected. We then ran another full-server test with Server Authority disabled, without making any other major network-related changes, and the experience was substantially smoother across the group. The receive rate also dropped by close to 100 KB/s.
Correlation doesn’t necessarily mean the additional bandwidth itself is causing the hitches. It could instead be something elsewhere in the Server Authority, NextGenerationReplication, input replication, or correction pipeline. But the difference between the two tests was significant enough that we didn’t want to dismiss it as an unrelated issue on our side yet.
We’d love to have you join a playtest if you are free. We can arrange something tomorrow if that works. Ideally, we could run back-to-back tests with Server Authority enabled and disabled under similar 12-player conditions so you can experience the difference directly.
Something worth noting, I wrote a pretty high level detailed post about how Server Authority works:
The above links to what I think may explain the hitches you are seeing. Server Authority is more CPU intensive on the Client, primarily when it needs to make corrections. Higher latency to server leads to a bigger performance spike. For example, if you have a player with 100ms RTT latency, you can expect their simulation load to increase 6x with Server Authority enabled because normally at 60Hz they simulate 16.6ms of physics, but with Server Authority they may need to roll back and resimulate.
There is some work we want to do to reduce these hitches, so participating in a playtest would be very useful to me to see how a real game uses Server Authority.
and shots occasionally not registering as expected
I would be curious how you are implementing hit detection, since for the time being we’re missing the “Server Rollback Hit Detection” logic that most common AAA shooters use. If you look at our Laser Tag demo, we still rely on a pretty loose server side “was this shot possible” check.
Our game is a fast-paced sports game where both high client performance and strong network performance are important. We ported our game over to Server Authority (twice now, LOL). The second time around I figured out how to debug it properly with the CTRL + SHIFT + F6 tool, and was able to significantly reduce the number of rollbacks at sub 150 ping. On my computer, it feels near perfect to before the port.
This round of implementation feels like I ALMOST nailed it. There’s a few small bugs, some which I believe are genuine Server Authority engine bugs (jumping on a baseplate template causes rollbacks), and other which are likely just an incorrect implementation. Unfortunately, our player base definitely still feels the effects of it not being implemented perfectly, and we’re likely going to swap back to a non-server-authority build. I believe what is driving downvotes to our game is a sub-60 FPS on non-PC devices, specifically an average of 25 FPS on mobile devices. I didn’t even consider client frame rate until I saw this comment about RTT & performance being directly correlated (double painful for mobile devices w/o ethernet). I think that frame rate makes the game unplayable given the fast-paced nature of the game.
However, I would love to playtest with you and see if it could help you better understand Server Authority in a production game. Any sort of debugging/optimization tips to understand how to reduce the number of mispredictions on lower-end devices would also be greatly appreciated! We’re building more sports into the game and nailing our Server Authority implementation early so we get the competitive benefits from it in every sport moving forward is important to us.