Connection/Lag

Bonjour à tous,

Voici mon soucis,

Lorsque le server atteint environs 30 - 40 joueurs en ligne certaine personne commence a laguer mais attention seulement ceux qui ont de faible connections ( car les 3/4 du server ne lag pas en faite et ceux qui lag sont souvent belge )

Voila alors je me demandais si le server ne privilégierais pas certain type de connections ou s'il était possible d'apporter des réglages a celui pour évité cela en fouillant les .properties j'ai trouver ses options:

Citation :

# =================================================================
# Threads configuration
# =================================================================

# Default 50
ThreadPoolSize = 50

Citation :

MaximumDbConnections = 100

Citation :

# Flood Protection
# If enabled players which send more then PACKETLIMIT packets in PACKETTIMELIMIT ms will get kicked
FloodProtection = False
PacketLimit = 500
PacketTimeLimit = 1100

Alors voila je me demandais s'il y avais possibilité d'améliorer la configuration server affin d'évité les lags a certaine personne ?

petite précision :

Rev: L2Jfree 1.2.9

Ram Allouée au GS ( 1536 )

Dédié ovh ( Windows 2003 Server )

° Processeur : Intel Core 2 Duo E6550
° Mémoire vive : 4 Go DDR2
° Disque dur : 750 Go SATA 2
° Connexion : 100 Mbps

( la population maximum est d'environs 50 joueurs en ligne )

Ou encore est ce que cela pourrais venir de mysql qui serais mal réglé ? faut il alloué aussi + de ram à mysql ? ( si oui comment ? )

Je suis preneur pour toutes les idées que vous aurez qui pourrais m'être utiles.

En vous remerciant grandement d'avance.

Pour m'en être fortement inspiré et avoir refait en partie le projet MMOCore, je peux dire qu'aucune amélioration ne peux être faite hors du serveur tout entier.

Pour tout te dire, tout cela viens du "KnownList" de chaque personnage principalement. Plus cette liste est grande, plus les packets envoyés et recus à chaque action seront nombreux (cela croit en carré) ... Hors, c'est très difficile de remplacer ça.

La meme chose arrive lorsque sur un HR, tu fais un gros train de mob a primeval island par exemple, tu as presque 1.5 seconde de ping, ce qui est énorme.

Le même phénomène touche tous les jeux tels que Counter Strike pour le plus connu de tous.

Parce que certains messieurs non pas touché à l'algorithmique avancée. Une algo bien foutue croit selon une fonction mathématique type ln car ce n'est pas possible de ne pas le faire croitre. Un algo qui croit au carré c'est un truc pas optimisé du tout. Le fonctionnement des knownlists avait été repensé en privé entre les dev' de L2JFree, des propositions ont été faites puis finalement ça n'a pas continué.

A vrai dire, ces algos sont déjà optimisés, le O(n²) est inévitable. Le seul problème, c'est que l'on reste avec un KnownList énorme qui recense tout, même ce qui est trop loin (donc un n trop grand).

J'avais pensé a faire une division par cellules de la carte pour réduire la taille des knownlist en ne prenant que ce qui est à portée, mais j'ai assez vite abandonné.

C'était basé sur le même principe que le projet de la geodata ? En utilisant les 8 cases entourant la case occupée par le PJ ?

Laguer a 30-40 Player, sur un dédié sur du 100Mb ce n'est pas normal... Ca ne devrait pas, même s'il est exact que les algo d'L2J de gestion des packets etc est à chier (C'est un fait et aucune des team chez L2J/L2JFree ne le nie, mais personne ne veut vraiment se plonger au coeur du problème)...

Grimly a écrit:

J'avais pensé a faire une division par cellules de la carte pour réduire la taille des knownlist en ne prenant que ce qui est à portée, mais j'ai assez vite abandonné.

En parlant des packets envoyés par le serveur, au tout début que je suis arrivé dans la Team chez L2J et après avoir parlé à un développeur qui lui aussi était français (Wooden qui a disparu depuis longtemps depuis XD), si je me souviens bien, il me disait que déjà sur l'off les packets étaient compressés et pas chez L2J. Info ou intox ?

Sinon petite réflexion que je me fait au sujet des zones que tu parles (C'est marrant parce qu'il me semblait que c'était géré les zones pour les envois de packets ), si tu définis un découpage de la map, tu vas avoir des cas particuliers à gérer, du genre un joueur qui est à la limite d'une zone, tu vas envoyer les packets pour 2 zones ou plus au lieu d'une nécessaire.

Donc réflexion, il me semble que dans les knowlist tu as déjà les méthodes pour sélectionner les éléments qui sont dans un certain "range", donc pourqquoi pas simplement sélectionner les éléments à envoyer dans un range "5000" (Valeur au pif, tout dépend de la capacité du jeu à afficher en profondeur, ça doit pas être si énorme) au moment T et ne faire qu'un envoi sur ces éléments ?

Oui je sais, faire ça on scratch ça peut être super lourd niveau CPU (Le travail sur les knowlist n'est pas réputé pour être super rapide et super efficace chez L2J). Mais ça permettrait d'assez simplement limiter la charge réseau en sacrifiant du CPU (Mais limite un CPU ça peut s'upgrader, la bande passante pas vraiment...).

Non ? Je me plante peut être je me suis jamais mis en tête de réellement me plonger dans la question Et ça fait un bon de temps que j'ai pas mis le nez dans du code L2J...

Ouai enfin c'est limité. Lancé un direct download bouffe bien plus de BP qu'un client sur un serveur l2j pourtant t'as pas besoin de 2 Go de RAM. Sur le réseau les paquets dépassent pas tant d'octets après t'as TCP et les buffers pour te foutre tout ça bien comme il faut.

L'idée de phpsteuf est pas mauvaise. Le principe des knownlists c'est "I know you, you know me" (en gros) donc forcément avec un grand nombre d'objets à un même lieu vivent les échanges de knownlists. C'est difficile de faire plus simple niveau compréhension et algorithmique. Faire bouffer plus le CPU pour alléger le réseau est pas con, une sorte de "prémonition" de dire "voilà les choses vont évoluer ainsi" donc pas besoin d'envoyer un max d'infos.

Non pas vraiment en l'occurrence ici. Met un disque 5400tr/min au lieu d'un super RAID la différence sera minime. L'accès disque n'a pas de répercutions sur le traitement des knownlists. Mais de manière globale ce que tu dis est juste.

Voilà, reste plus qu'à mettre en place et faire des benchs Difficile d'évaluer les répercutions sur le CPU d'une telle rustine (Parce que c'est bien une rustine, tout le système de Knowlists est en cause...). Parce qu'il est possible que la monté en charge du CPU ne soit pas acceptable par rapport au gain réel au niveau réseau, seul des tests donneront des réponses exactes, j'ai pas en tête la complexité des knowlists ainsi que les délais d'envois des paquets moyens etc etc... Pour les gains réseaux je me fait pas de bille, les résultats pourraient même être très surprenant

Qui se lance ? XD

Citation :

Sinon petite réflexion que je me fait au sujet des zones que tu parles (C'est marrant parce qu'il me semblait que c'était géré les zones pour les envois de packets scratch ), si tu définis un découpage de la map, tu vas avoir des cas particuliers à gérer, du genre un joueur qui est à la limite d'une zone, tu vas envoyer les packets pour 2 zones ou plus au lieu d'une nécessaire.

Mon idée est justement de diviser en très petites parties (500 de coté, sachant que la parole a une portée de 5000). Par contre, si ce n'est pas travaillé avant d'être codé, on peux sentir l'explosion de mémoire utilisée.

Personnellement, je suis limité par le mouvement des personnages, mais j'ai déjà réduit de beaucoup les complexités temporelles et de mémoire.