La solution a ça est d'avoir 2 tables.

Celle de jeu avec tous les événements récents (datant de moins de n jours).

et 1 table d'historique avec les événements à garder absolument (entrainement, amélioration, mort, don de PXs, ...)

Ton gros fichier deviendrait vite illisible et inutilisable... on parle de 2GOs!
A partir de quelques mégas, un fichier devient illisible

prkoi ne pas simplifier la structure de cette table ?

avec des numéros sur plusieurs champs plutôt que du texte entier.

Sur l'optimisation, je fais confiance à l'équipe : s'ils estiment que le jeu ne supporte plus de garder en mémoire accessible à tous via les évènements autant de données, ils les limiteront et basta.

Il est bien entendu évident que je préfère un jeu qui tourne et ne pas avoir accès à certaines infos que le contraire.

Cependant, sans aller non plus trop longtemps en arrière, je trouve que conserver les ev de mort, d'entrainement et de don d'XP pendant plusieurs mois est pas mal, assez utile tout de même, permet de voir le "caractère" d'un troll croisé dans les souterrains.
De même je trouve tout de même pas mal d'avoir les ev de combat, d'achat et de ramassage des 2 ou 3 dernières semaines.
On s'y ferait si ça disparaissait bien entendu, mais je crois que seule l'équipe est en mesure de savoir ce qui arrangerait les choses de manière significative.

C'esun bonne idée

par contre faut voir au nivo des missions si ca pose pas des probs car y a des étapes qui dure longtemps ...

pour les missions, les requêtes peuvent se faire sur la table parallèle, avec toutes les infos.

je suis assez pour diminuer le durée de vie de evmnt, si cela peut aider

Limitez au maximum si cela doit alléger (c'est un informaticien qui vous parle).

Cependant quatre remarques quand même :

1) Il faut "absolument" pouvoir déterminer l'alignement d'un troll que l'on croise (TK, MK, queud', ou un mix de tout ça). Donc faut pouvoir garder les évènement de mort très longtemps. Si on fait une table "à côté" juste pour cela, le problème restera malheureusement le même, parce que cette table va grossir. Donc pas facile... Sans avoir vu le schéma relationnel de votre base.

Une idée peut-être, ne garder que les dix derniers évènement de type MORT, ce qui est suffisant pour voir si un troll est TK, MK, etc... Et dans une table "à côté" si ça peut arranger. Il "suffirait" de faire un COUNT des entrées dans la table, et s'il y en a déjà 10, on en vire une (après avoir ajouté la dernière). Certes, ça rajoute pas mal de traitement pour chaque evt MORT... C'est difficile à dire si c'est mieux comme ça à vide, sans connaître la conception.

2) A ce propos, elle est où la ML dédiée aux informaticiens qui voudraient aider ? (et dont il avait été question dans les forums ? J'ai cru avoir lu qu'elle existait maintenant ?)

3) Il faut garder aussi les Evts de DON pour traquer les MT. Certes, même si personnellement j'aime à dénicher ce genre d'enfoiré de joueurs qui nuisent à l'esprit du jeu, c'est une connaissance dont pourraient se passer les joueurs. Donc ce pourrait être stocké "ailleurs", juste à dessein des Enquêteurs. A moins que là aussi on ne garde pour les joueurs, en plus de la table "à côté" pour les Enquêteurs, les derniers evts de DON pour permettre aux joueurs de voir si deux trolls qui s'approchent jouent ensemble ou pas. Mais je pense qu'on peut s'en passer sinon.

4) A propos des Missions / Evts :

Pour avoir vu les problèmes liés à la longueur et la difficulté de Valider une Etape d'une Mission, il me semble que l'action de Validation parse tous les évènements depuis la date stockée de début de réalisation de l'Etape. Une telle pratique est bien évidemment tout à fait non optimisée et lourde pour le serveur (on en a vu les impacts à une époque où cela ne coûtait pas 1 PA pour Valider). Ne lisez pas la suite si je me suis planté en supposant comment ça marche. Une autre conséquence de cela, c'est qu'il faut pouvoir garder les évènements (du moins une bonne partie d'entre eux : tous ceux susceptibles d'être impliqués dans la vérification d'une Validation d'une Etape) pendant une durée indéterminée, car le Meneur et son équipe peuvent mettre le temps qu'ils veulent pour réaliser une Etape. Ce point là empêcherait de limiter le stockage des evts.

Une solution serait de changer le fonctionnement de la gestion des Etapes d'une Mission. Ca allègerait la Validation, et permettrait de ne pas stocker les evts au delà d'une certaine durée, ce qui est le but de ce thread.

Pour ce faire, il faudrait revoir la gestion de Missions (ça doit être lourd :-( ) pour qu'à chaque type d'Etape soit associé un descriptif (dans une table) des evts à logguer pour tracer la réussite de cette Etape, et qu'ensuite un flag soit activé au niveau des participants d'une Mission et qu'à chacun des évènements d'un des membres de l'équipe, si le flag est activé, on loggue l'évènement dans une table *dédiée* à la validation des Missions (avec par exemple comme entrée : noMission, evt). Lors de la Validation de l'Etape d'une Mission, c'est cette table qui serait parsée avec la clé de la Mission. Ce serait beaucoup plus optimisé. Et si l'Etape est validée, on vide ladite table des evts loggués jusqu'à présent. On y logguera les evts liés à la prochaine Etape.

Pour m'occuper moi-même d'un pbem, j'entrevois bien sûr que toute reconception demande un travail énorme...

J'essayais juste d'aider, j'espère avoir contribué un peu à cela. Sinon je suis désolé pour tous ceux que j'ai sâoulé avec un post aussi long !

Grognon, Relais&Mago.

Et si on essayait de s'affranchir de la limite (obsolete il me semble) de 2Go  ?

http://dev.mysql.com/doc/mysql/fr/Table_size.html

1.2.4 Quelles tailles de tables supporte MySQL ?

MySQL version 3.22 a une limite de 4Go par table. Avec le nouveau format de table MyISAM, disponible avec MySQL version 3.23, la taille maximale des tables a été poussée à 8 millions de teraoctets (2 ^ 63 octets).

Notez, toutefois, que les systèmes d'exploitation ont leur propres limites. Voici quelques exemples :

Système d'exploitation  Limite 
Linux-Intel 32 bit  2Go, 4Go ou plus, suivant la version de Linux 
Linux-Alpha  8To (?) 
Solaris 2.5.1  2Go (4Go possibles avec un patch) 
Solaris 2.6  4Go (peut être modifié avec une option) 
Solaris 2.7 Intel  4Go 
Solaris 2.7 UltraSPARC  512Go 

En Linux 2.2, vous pouvez avoir des tables plus grandes que 2Go en utilisant le patch LFS pour les systèmes de fichiers ext2. En Linux 2.4, le patche existe aussi pour ReiserFS.

Cela signifie que les tables MySQL sont généralement limitées par le système d'exploitation.

Y a-t'il un endroit plus approprié pour ce post ?

a+

Juste pour dire que je ne me sers pas seulement des dons de PX pour savoir si j'ai à faire à un multi mais assez souvent pour savoir si j'ai à faire à quelqu'un qui partage après un kill

Les évènements permettent de déterminer le caractère d'un troll qui n'est pas toujours "transparent" dans sa description, et je les trouve donc très intéressants : avoir les 10 dernières morts ça me parait peu.

Bien entendu, si la survie du jeu est en jeu (ahem), on n'en parle plus et on bazarde un max d'évènements mais si y'a moyen d'en garder pas mal au niveau morts/combats/dons/achats ça serait quand même bien sympa.

Il serait intéressant d'avoir des stats globales sur le nombre d'évènements de chaque type.

J'intuite que les évènements de type "déplacement" sont assez nombreux (et peu informatifs à mon avis, après tout, les monstres ne les ont pas!) et avoir une durée de vie très limitée pour ce type d'évènement ne serait pas grave du tout (voire les supprimer complètement?)

Quant aux évènements "mort" ou "amélioration", j'ai dans l'idée qu'ils sont si peu nombreux (en proportion) que tous les garder ou n'en garder que certains n'aura pas beaucoup d'impact sur les performances.

Bref l'idée est simple : taper sur les évènements les plus nombreux en premier, non?