Ceux présents l'ont remarqué, le second test de Totem a été complètement parasité par les lags/freezes.
Ça en a agace beaucoup et c'est d'autant plus incompréhensible puisqu'il n'y avait "que 150 joueurs".
Pour que vous puissiez comprendre la situation, je vais vous faire un petit résumé sur les performances et le fonctionnement des serveurs Minecraft :
À chaque "tick", le serveur fait un certain nombre d'opérations :
Lorsque le serveur ne lag pas :
Il met moins de 50ms pour exécuter 1 tick. Par exemple, s'il met 10ms seulement, il attendra ensuite 40ms sans rien faire avant le tick suivant.
Ressenti : Le jeu est fluide.
Lorsque le serveur est surchargé :
Il se peut qu'il mette plus de 50ms pour exécuter un tick ! Par exemple, s'il met 75ms, il ne sera plus capable d’exécuter les 20 ticks par seconde comme attendu (il ne pourra en exécuter que ~13... - 1000ms/75ms = ~13).
Ressenti : les joueurs ont une sensation de latence : les entités se déplacent plus lentement (on le remarque surtout avec les flèches, enderpearls, etc), les joueurs se "téléportent", etc.
Il y a également une dernière possibilité :
Lorsque le serveur ne lag pas, mais a des surcharges aléatoires :
Le serveur met moins de 50ms pour exécuter 1 tick en général, mais d'un coup il va mettre 400ms à en exécuter 1 (peut-être parce qu'une opération sera anormalement longue, comme une mise à jour de lumière). On appelle ça des "lag spikes" ("pointes de lag" traduit en français).
Ressenti : Le jeu est fluide, mais par moment tout s'arrête de bouger.
Pour pallier à ça, nous utilisons des "proxys" (BungeeCord et Velocity sont les plus connus) qui redirigent de façon transparente les joueurs vers différents serveurs.
Par exemple, FunCraft n'est pas un énorme serveur capable d'accueillir plus de 5000 joueurs. En réalité il s'agit de plein de petits serveurs aux capacités différentes (les hubs/lobbys à 150+ slots, les serveurs Rush/Skywars/... à ~20 slots, etc).
Le problème des PvP/Factions est que l'objectif est souvent d’accueillir le maximum de joueurs sur un seul monde (et donc un seul serveur).
Pour nous l'opération est en bonne voie puisque le serveur a été capable d'accueillir 450 joueurs sur le même monde sans lags (pour un serveur PvP ce chiffre est en général plus proche des 300 - d'ailleurs c'est fou le nombre de serveurs Factions qui trichent/mentent sur leur nombre de joueurs connectés, il faudra qu'on en discute un jour).
Ce genre d'optimisations ne se fait pas par magie, c'est un processus long qui dure dans le temps.
Pour les lags "classiques", on analyse les parties du code qui mettent en moyenne le plus de temps à s'exécuter à chaque tick et on essayer de réduire leur temps d'exécution (en utilisant de meilleurs algorithmes, etc).
Pour les "lag spikes", il faut en premier identifier les opérations qui durent parfois trop longtemps et essayer de les lisser sur plusieurs ticks.
Surprise : non, ce n'est pas ça. La tick-loop n'avait aucun lag et mettait moins de 20ms pour exécuter chaque tick, donc aucun problème pour les 20 ticks par seconde ! Absolument aucun tick n'a excédé les 50ms.
Mais alors, d'où viennent ces lags lors du totem ?! Et bien c'est la question en or... Malheureusement je n'avais pas les outils nécessaires pour analyser tout ce qu'il se passait lors de ce totem (car je m'attendais à ce que les lags éventuels viennent de la tick-loop).
J'ai quelques pistes (principalement côté réseau/packets), mais il faudra encore faire des "totems qui lags" pour pouvoir comprendre puis corriger ça. C'est le pire dans ce genre de situations : il faut la reproduire pour pouvoir la corriger... Surement même qu'il faudra la reproduire plusieurs fois.
Pour ceux qui veulent quelques info supplémentaires :
---
Il faudra surement encore plusieurs tests de totems ratés pour le corriger... Mais avant je dois finir de préparer tous les outils nécessaires pour analyser tout ça.
On va surement faire des totems sous forme de "mini-jeux" pour faciliter ces tests (le stuff ne sera pas lié au reste du faction et tout le monde sera p4u3 avec pots, etc).
Ça en a agace beaucoup et c'est d'autant plus incompréhensible puisqu'il n'y avait "que 150 joueurs".
Pour que vous puissiez comprendre la situation, je vais vous faire un petit résumé sur les performances et le fonctionnement des serveurs Minecraft :
Fonctionnement du serveur MC
La "tick loop"
Comme pour la majorité des serveurs de jeux, le serveur MC est piloté par une "boucle" principale. Cette boucle se répète et chaque exécution est appelée un "tick".À chaque "tick", le serveur fait un certain nombre d'opérations :
- traiter les packets entrants des joueurs (attaques, déplacements, placement de blocs, ...) ;
- mettre à jour le monde (redstone, eau, ...) ;
- faire spawn les mobs et traiter leur IA ;
- mettre à jour la position des joueurs et des entités ;
- etc.
Lorsque le serveur ne lag pas :Il met moins de 50ms pour exécuter 1 tick. Par exemple, s'il met 10ms seulement, il attendra ensuite 40ms sans rien faire avant le tick suivant.
Ressenti : Le jeu est fluide.
Lorsque le serveur est surchargé :Il se peut qu'il mette plus de 50ms pour exécuter un tick ! Par exemple, s'il met 75ms, il ne sera plus capable d’exécuter les 20 ticks par seconde comme attendu (il ne pourra en exécuter que ~13... - 1000ms/75ms = ~13).
Ressenti : les joueurs ont une sensation de latence : les entités se déplacent plus lentement (on le remarque surtout avec les flèches, enderpearls, etc), les joueurs se "téléportent", etc.
Il y a également une dernière possibilité :
Lorsque le serveur ne lag pas, mais a des surcharges aléatoires :Le serveur met moins de 50ms pour exécuter 1 tick en général, mais d'un coup il va mettre 400ms à en exécuter 1 (peut-être parce qu'une opération sera anormalement longue, comme une mise à jour de lumière). On appelle ça des "lag spikes" ("pointes de lag" traduit en français).
Ressenti : Le jeu est fluide, mais par moment tout s'arrête de bouger.
Limites du serveur MC
Il n'est pas possible d'exécuter les opérations de la tick loop en parallèle. Ce qui fait que les serveurs MC sont forcément limités à un certain nombre de joueurs, même en achetant le processeur le plus puissant du monde !Pour pallier à ça, nous utilisons des "proxys" (BungeeCord et Velocity sont les plus connus) qui redirigent de façon transparente les joueurs vers différents serveurs.
Par exemple, FunCraft n'est pas un énorme serveur capable d'accueillir plus de 5000 joueurs. En réalité il s'agit de plein de petits serveurs aux capacités différentes (les hubs/lobbys à 150+ slots, les serveurs Rush/Skywars/... à ~20 slots, etc).
Le problème des PvP/Factions est que l'objectif est souvent d’accueillir le maximum de joueurs sur un seul monde (et donc un seul serveur).
Optimisations
Évidemment le premier objectif sur un serveur accueillant des très nombreux joueurs est d'optimiser au maximum toutes les opérations de la tick loop pour pouvoir accueillir le maximum de joueurs sans lags !Pour nous l'opération est en bonne voie puisque le serveur a été capable d'accueillir 450 joueurs sur le même monde sans lags (pour un serveur PvP ce chiffre est en général plus proche des 300 - d'ailleurs c'est fou le nombre de serveurs Factions qui trichent/mentent sur leur nombre de joueurs connectés, il faudra qu'on en discute un jour).
Ce genre d'optimisations ne se fait pas par magie, c'est un processus long qui dure dans le temps.
Pour les lags "classiques", on analyse les parties du code qui mettent en moyenne le plus de temps à s'exécuter à chaque tick et on essayer de réduire leur temps d'exécution (en utilisant de meilleurs algorithmes, etc).
Pour les "lag spikes", il faut en premier identifier les opérations qui durent parfois trop longtemps et essayer de les lisser sur plusieurs ticks.
Le problème des totems
Suite à ces informations, on pourrait croire que lors du totems il y avait des "lag spikes" venant de la tick-loop : les joueurs arrêtaient tous de bouger d'un coup par moment.Surprise : non, ce n'est pas ça. La tick-loop n'avait aucun lag et mettait moins de 20ms pour exécuter chaque tick, donc aucun problème pour les 20 ticks par seconde ! Absolument aucun tick n'a excédé les 50ms.
Mais alors, d'où viennent ces lags lors du totem ?! Et bien c'est la question en or... Malheureusement je n'avais pas les outils nécessaires pour analyser tout ce qu'il se passait lors de ce totem (car je m'attendais à ce que les lags éventuels viennent de la tick-loop).
J'ai quelques pistes (principalement côté réseau/packets), mais il faudra encore faire des "totems qui lags" pour pouvoir comprendre puis corriger ça. C'est le pire dans ce genre de situations : il faut la reproduire pour pouvoir la corriger... Surement même qu'il faudra la reproduire plusieurs fois.
Pour ceux qui veulent quelques info supplémentaires :
- pas de soucis de tps donc, aucun tick n'a excédé les 50ms
- pas de soucis liés à la GC (aucune GC n'a excédée les 2ms et elles étaient toutes très espacées)
- peu probable que le souci soit lié aux threads netty du spigot (j'avais quelques outils d'analyses pour ça - mais je vais quand même les monitorer la prochaine fois, sais-t-on jamais)
Le soucis semble donc ne pas venir du spigot directement ?! Il faut donc monitorer les proxys.
Si le pb n'est lié ni au spigot ni au proxy alors il faudra envisager de monitorer le réseau (maybe un pb spigot<->bungee ou bungee<->client).
En soit la rencontre de 150 joueurs dans une zone minuscule qui sont en full pvp c'est assez intense, en out/joueurs on a :
- 20pps de déplacement
- ~8 pps de swing de mains
- qq pps pour le sneak, les metadata de fire, etc
On voit bien l'explosion du traffic out sur ce graph pendant les quelques minutes du totem (rose : bungee, violet : spigot du totem) :
- pas de soucis liés à la GC (aucune GC n'a excédée les 2ms et elles étaient toutes très espacées)
- peu probable que le souci soit lié aux threads netty du spigot (j'avais quelques outils d'analyses pour ça - mais je vais quand même les monitorer la prochaine fois, sais-t-on jamais)
Le soucis semble donc ne pas venir du spigot directement ?! Il faut donc monitorer les proxys.
Si le pb n'est lié ni au spigot ni au proxy alors il faudra envisager de monitorer le réseau (maybe un pb spigot<->bungee ou bungee<->client).
En soit la rencontre de 150 joueurs dans une zone minuscule qui sont en full pvp c'est assez intense, en out/joueurs on a :
- 20pps de déplacement
- ~8 pps de swing de mains
- qq pps pour le sneak, les metadata de fire, etc
On voit bien l'explosion du traffic out sur ce graph pendant les quelques minutes du totem (rose : bungee, violet : spigot du totem) :
---
Conclusion
Ce problème reste la dernière grosse barrière avant la vraie ouverture du serveur... dès qu'il sera réglé on pourra enfin démarrer les totems, le classement, la pubs !Il faudra surement encore plusieurs tests de totems ratés pour le corriger... Mais avant je dois finir de préparer tous les outils nécessaires pour analyser tout ça.
On va surement faire des totems sous forme de "mini-jeux" pour faciliter ces tests (le stuff ne sera pas lié au reste du faction et tout le monde sera p4u3 avec pots, etc).
