#High receive bandwidth (Empfangen ~200+ KB/s) causes lag in Roblox simulator

1 messages · Page 1 of 1 (latest)

icy dome
#

Hi, I need help with a network performance issue in my Roblox simulator game.

I’m getting high network traffic in the Roblox performance stats, especially Receive (Empfangen):

Sent (Gesendet): ~53 KB/s
Receive (Empfangen): ~213 KB/s
When this happens, gameplay becomes noticeably laggy/stuttery, especially as more objects are placed.

Problem scope
This ticket is only about network traffic being too high (not UI overlap, not rendering visibility bugs).

What I already implemented
Client request throttling for place/remove/link actions
Partial state updates (itemInventoryDelta) in some places
Reduced billboard distances and reduced some update frequencies
Disabled some visual animations/FX for performance
What I need help with
I want to reduce Receive bandwidth significantly without breaking gameplay responsiveness.

Questions
What is the recommended target range for receive bandwidth per client in games with many placed objects?
Best pattern for state replication: full snapshot + deltas, or pure event-driven deltas?
How do you usually batch/throttle frequent server updates (power links, production stats, billboards) safely?
Are there common replication pitfalls with many dynamic parts/models I should audit first?
If helpful, I can share my current RemoteEvent update flow and state payload structure in code blocks.

image.png image.png
crystal dock
#

200 is too high

#

Best pattern for state replication: full snapshot + deltas, or pure event-driven deltas?
depends what it is, most things should be event driven deltas only

#

but even within that, it depends what it is

#

How do you usually batch/throttle frequent server updates (power links, production stats, billboards) safely?
power links are not a standard roblox thing so it depends what that is

#

same with production stats

#

what is that

icy dome
#

In my game, “power links” are custom server-to-machine connection states (including link/unlink/link-all and visual link lines), and “production stats” are custom per-player rates/states (data/sec, money/sec, energy usage/link counts, market multiplier). I’m currently trying to send these as event-driven deltas instead of frequent full updates.

crystal dock
#

Are there common replication pitfalls with many dynamic parts/models I should audit first?
what is in your game?

#

can you link this game or show recording of it?

#

coz it sounds like you want help figuring out where the data is coming from

supple forum
icy dome
#

is publish u can go

supple forum
#

cool

crystal dock
#

it has a backdoor in it

#

missing tutorial

icy dome
#

yes i am in Beta with this game

empty prismBOT
#

studio** You are now Level 1! **studio

bronze copper
crystal dock
#

your game has a lua virus in it i suggest you fix that at some point before full release (this is the second prompt, there was a first one about 'crazy hack something')

icy dome
#

oh noooo shit

#

i do serve now offline

crystal dock
#

it didn't look like there was many things moving in your game so it's probably the data you're sending periodically

#

you probably don't need to send anything after buildings are placed

#

only when things change

#

like is money per second increasing every second? probably not. and if it was, send the current money per second, send a time stamp, send growth formula variables, send all that once, and let the client calculate it on its own.

#

then you don't really need to send any periodic data at all

#

but also you have lua virus so who knows

icy dome
#

That makes sense, thanks. I likely still send too much periodic data (state/power/production updates).
I’ll move more systems to event-driven deltas only and reduce periodic replication to a minimum.
For production, I’ll send base rate + timestamp and let the client calculate locally.

#

Thanks again — could you help me with concrete implementation choices?

  1. For production/data gain:
    Should I send only {baseRatePerSec, serverTimeStamp, modifiers} on change events and let the client integrate locally between events?
    If yes, what correction strategy do you recommend (hard snap vs lerp) when drift happens?

  2. For power links:
    Would you replicate only link/unlink events (delta list) and keep client-side derived totals,
    instead of periodic full power state payloads?

  3. For periodic updates:
    What minimum keepalive frequency would you use for idle-sim HUD state (5s / 10s / only on open panel)?
    I currently want to remove most 1s periodic sends.

  4. For Roblox replication:
    What should I audit first to reduce recv bandwidth in games with many placed models?
    (e.g. changing part properties too often, attributes, CFrame updates, ValueObjects, FX parts)

  5. Target:
    Is ~50 KB/s recv still a good target per client for this genre, and what upper limit would you consider acceptable during heavy activity?

crystal dock
#

its just numbers

#

simple stats really

#

per-object stats but still very simple

#

your efforts to optimize prematurely / early on is probably why your bandwidth is high

#

but its fine you'll get there

#

lots of parts moving on the server will produce 50kB/sec and more very easily

#

but if you don't have any moving parts you have little to no excuse

#

50kB/sec is a good target for any game regardless of genre

icy dome
#

Quick follow-up: for an idle simulator with mostly numeric state and no moving parts, would you target:

  • pure on-change deltas + rare keepalive (e.g. 8–10s),
  • and client-side predicted production (rate + timestamp + modifiers)?
    Also, what drift correction threshold would you use before server snap (e.g. >1–2% or >N units)?
    Would you do pure on-change deltas + 8–10s keepalive, and client-side production prediction (rate+timestamp)? What drift threshold is best before snap-correction?
icy dome
#

Quick update: I disabled the heavy animations and my receive bandwidth is now around 35 KB/s (avg ~36), so network is much lower than before.

But I still feel stutter/lag. So I think the bottleneck is no longer bandwidth, but CPU/render/physics/script workload.

Could you help me identify likely non-network bottlenecks in an idle simulator with many placed objects?
I can profile and share:

  • Script Activity spikes
  • MicroProfiler captures
  • Frame time / render stats
  • Physics ownership/collision checks
image.png image.png
crystal dock
crystal dock
#

it's like configuring a spring, how much dampening should you use? idk try a few things out, maybe calculate some thresholds and go with that.

crystal dock