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

Libro blanco del lag en juegos › L9 Proceso del juego en el servidor

Costo de serialización y compresión Serialization / compression cost

ID de la causa sp-serialize · Responsable principal Desarrollo de servidor (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Convertir a bytes y comprimir los datos que se van a enviar también consume CPU, y con mucha gente este costo se dispara.

Por qué En cada actualización, se convierten estructuras a bytes y se comprimen → Efecto El costo crece con el cuadrado del número de jugadores → En pantalla El envío se retrasa: input lag

Síntomas
Input lag
Factores
Detención, Latencia
A quién afecta
Una zona o un canal
Cuándo
Cuando se junta mucha gente
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Reutilizar para varios jugadores un paquete ya generado, usar formatos ligeros.
En el gráfico
Sube con la carga · Uso de CPU del servidor, CPU del hilo que genera los paquetes
Dónde mirar
Con perf top -p, peso de las funciones de serialización, compresión y cifrado (incluidas las de bibliotecas como zlib, LZ4 u OpenSSL) en el tiempo de CPU del proceso del juego, comparando momentos con pocos jugadores y con aglomeración
Se confirma si
Cuanto más se junta la gente, más pesan las funciones de serialización, compresión y cifrado, y la CPU del hilo que genera los paquetes es la primera en saturarse
Se descarta si
Si estas funciones pesan poco, apunta al cálculo de visibilidad o a la lógica del juego
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Si la conexión cifra los paquetes (TLS, DTLS, etc.), cifrar y descifrar también consume CPU. El cifrado se hace por conexión, así que, aunque un paquete generado se reutilice para varios jugadores, el costo de cifrado se paga una vez por destinatario. Los cifrados simétricos como AES-GCM son tan rápidos que un núcleo procesa varios GB por segundo y normalmente pesan poco, pero su velocidad varía mucho según el tamaño de la unidad que se cifra de una vez (registro), así que, con muchos paquetes pequeños como en un juego, el costo por byte aumenta. En el handshake, que se hace una vez por conexión, el servidor firma con la clave del certificado y calcula el intercambio de claves (ECDHE). Un núcleo hace entre unas 1,100 (RSA 2048) y 18,000 (ECDSA P-256) firmas por segundo, y unos 9,000 intercambios de claves, así que la carga se nota cuando se concentran los inicios de sesión.

Fuentes

  1. Introduction to Iris in Unreal Engine Epic Games
    Mantener una sola copia cuantizada del estado a replicar reduce el trabajo costoso, que se comparte entre varias conexiones
  2. VALORANT's 128-Tick Servers Riot Games
    Comparar en cada frame las variables replicadas de cada cliente y agrupar los valores cambiados es lento porque lee memoria dispersa, y consume mucha CPU del servidor
  3. How "expensive" is crypto anyway? Cloudflare
    Mediciones de BoringSSL: AES-128-GCM a unos 3.7 GB por segundo (varía mucho según el tamaño del registro); por núcleo y segundo, 1,120 firmas RSA 2048, 18,477 firmas ECDSA P-256 y 9,394 ECDHE P-256; en los servidores edge de Cloudflare, la biblioteca TLS consumía alrededor del 1.8% de la CPU
  4. perf-top(1) — Linux manual page perf
    Muestra en tiempo real el peso de uso de CPU por función (símbolo) de un proceso en ejecución (-p)

Ver también

Misma capa: L9 Proceso del juego en el servidor

Causas de otras capas con el mismo síntoma (Input lag)

Ver la ficha interactiva con gráficos y simulaciones