한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game Lag White Paper › L9 Server game process

Serialization and compression cost Serialization / compression cost

Cause ID sp-serialize · Primary owner Game team (Server development)

Open the interactive card with figures and simulations →

Turning outgoing data into bytes and compressing it takes CPU too, and with many players this cost explodes.

Why Structs are converted to bytes and compressed for every update → Effect Cost grows with the square of the player count → On screen Sends go out late: input lag

Symptoms
Input lag
Factors
Stall, Latency
Who’s affected
Specific zone/channel
When
When crowds gather
Owner
Primary owner Game team (Server development)
Game team action items
Reuse a packet built once for many players, use a lightweight format.
On the graph
Rises with load · Server CPU utilization, CPU of the thread that builds packets
Where to look
Share of the game process’s CPU time spent in serialization, compression, and encryption functions (including library functions such as zlib, LZ4, and OpenSSL) from perf top -p, compared between quiet and crowded times
Confirmed if
The more players crowd in, the bigger the share of serialization, compression, and encryption functions, and the thread that builds packets saturates first
Ruled out if
These functions take a small share: points to AOI calculation or game logic
Check with
Infra tools (no game code needed)
Learn more
If the connection encrypts packets (TLS, DTLS, and so on), encryption and decryption use CPU too. Encryption is done separately for each connection, so even when one built packet is reused for many players, the encryption cost scales with the number of recipients. Symmetric ciphers such as AES-GCM are fast enough for one core to handle several GB per second, so their share is usually small, but their speed varies widely with the size of the unit encrypted at once (the record), and with many small packets, as in games, the cost per byte goes up. In the handshake done once per connection, the server signs with its certificate key and computes the key exchange (ECDHE). One core can do about 1,100 (RSA 2048) to 18,000 (ECDSA P-256) signatures and about 9,000 key exchanges per second, which becomes a burden when logins surge.

Sources

  1. Introduction to Iris in Unreal Engine Epic Games
    Holds the state to replicate as a single quantized copy to cut expensive work, and shares that work across connections
  2. VALORANT's 128-Tick Servers Riot Games
    Comparing replicated variables for each client every frame and bundling the changed values reads memory all over the place, which is slow and costs a lot of server CPU
  3. How "expensive" is crypto anyway? Cloudflare
    BoringSSL measurements: AES-128-GCM about 3.7 GB per second (varies widely with record size); per core per second, 1,120 RSA 2048 signatures, 18,477 ECDSA P-256 signatures, and 9,394 P-256 ECDHE operations; on Cloudflare edge servers, the TLS library used about 1.8% of CPU
  4. perf-top(1) — Linux manual page perf
    Shows live CPU share per function (symbol) for a running process (-p)

See also

Same layer: L9 Server game process

Same symptom (Input lag), other layers

View the interactive card with figures and simulations