P.o.o. Qu'est-ce Qu'on Stocke En Session Ou Pas ?

[Sybler]

Bonjour, j'ouvre un autre aspect du débat sur la P.o.o.
À savoir ce que vous stockez en session pour sauver des requêtes SQL et ce que vous ne stocker PAS parceque ca change trop souvent.

Dans mon cas je stocke la liste des personnages qu'un joueur possède.
Je stokais aussi les informations sur le personnage et l'inventaire, sauf que j'ai réalisé qu'en bout de ligne ca me fesait sauver que 3ms.

3ms considérant que je doit: gérer le rafraichissement dans le cas ou un personnage tiers modifie une valeur d'un joueurs actuellement connecté, juste la je reperd le 3ms de gain en validation de est-il online ? + Update un champs MySQL qui dit de "recharger" le personnage.


Bref, vous, vous stockez quoi en session ?
Comment gérez-vous les informations souvent modifiées ?

[manakeo]

Je me posais la meme question il y a peu.
En codant en OO, ne faudrai-til pas stocker ces objets créé dans les sessions?
Désolé de ne pas avoir de réponse pour toi Sybler, mais j'attends autant que toi des réponses lol.

PS: encore une fois au cas ou tu l'aurais pas vu, je t'ai envoyé un mail avec mon msn ^^

[Sybler]

Si si je l'ai vu, je t'ai d'ailleurs ajouté depuis maintenant... quelques jours en fait :-\

En fait j'ai procédé à des tests par moi-même concernant le stockage en session de mon objet PERSO (qui comprend environ 40 attribut, incluant un objet LIEU, pour le lieu actuel du perso et un tableau d'objet ITEM pour l'inventaire du personnage)

Sur le temps de génération TOTAL de la page (MySQL+Php), je sauvais en moyenne 3ms à stocker perso en session.

MAIS, le problème qui se pose est que je dois gérer manuellement un "rafraichissement forcé". Par exemple si je joue avec mon personnage "Bob", "Bob est stocké en session. Les page chargent 3ms plus vite (yé!) . Sauf que, pendant que je suis connecté et que je joue, "Garry" m'attaque et me fait perdre 5 points de vie. "Garry" doit d'une facon X me forcer à faire recharger mon "Bob" car sinon je verais jamais les 5 PV qu'il m'a fait perdre jusqu'à ce que je me reconnecte au jeu.

Donc cela veux dire que pour chaque action qui modifie une valeur au perso, je devrait effectuer une requête MySQL supplémentaire qui indique que le perso concerné (dans notre cas "Bob") doit-être rechargé car il à été modifié.


Pour vérifier ce champs, c'est donc une requête de plus sur chaque page.

De fil en aiguille le 3ms de moins viend de s'amoindrir et de complexifier beaucoup de choses.


Donc j'ai pris la décision de NE PAS stocké le personnage en session vu qu'il est trop sujet à des modifications.

Actuellement ma page principale fait ceci:
- Elle charge et affiche la liste des personnage associé au compte
- Elle charge et affiche les statistiques du personnage actuellement joué
- Elle charge l'inventaire complet en mémoire et calcule et affiche l'espace qu'occupe les items
- Elle charge les attributs du lieu actuel (nom, description, etc) et affiche le nom
- Elle charge et affiche la première page de l'historique des évènements du personnage
- Elle génère le menu d'action en fonction de l'état du personnage, du lieu ou il se trouve et des items qu'il possède.


Le tout me prend 15 requêtes et prend moins de 0.09 secondes à générer.
Est-ce l'optimisation de 3ms est réellement requise ?


Edit:
Je viend de vérifier pour ton email:
*******@hotmal.com
t'a oublié le "i" .. et moi j'aime bien copier-coller ....
Je te ré-ajoute.

[Ludvig]

Perso je stoque uniquement les donnés qui ne vont pas changer...

Comme le login par exemple.
Les characs de base pourrait être stoqués, mais bon, le jour
ou tu inventera le sortilège "augmenter la force d'autrui" il
faudra faire comme Sybler indique (et en fait pas le faire du tout ^^).

L'idé des pluparts des jeux est justement que les donnés changent
donc utiliser la session comme un cache et probablement plus compliqué que benefique.
Ceci dit, si il y a des donnés qui change uniquement après action du joueur même,
ils peuvent bien être stoqués dans la session.
Comme l'argent ou son equipement.

C'est pas piratable, non ?
Je me sopuviens du vieux php où les variables normaux se confondait avec les variable
du session ... (c'est plus le cas j'espère) enfin je crois.

[Sybler]

C'était plus à cause du REGISTER_GLOBAL je crois...

[Tarot]

Avec AJAX, c'est point possible d'avoir un synchronisme au niveau de la reactualisation des données ?

On envoie une demande de réactualisation. La page chargée de vérifier le contenu des variables tourne en boucle tant que les variables ne changent pas avant de renvoyer les données.
AJAX fait son bazard et corrige la page avec les nouvelles données sans que l'utilisateur ait le besoin de faire une action précise.

Bon par contre, ca doit bien manger niveau ressource si c'est faisable ^^".

[Sybler]

ca signifirais que ca serait encore pire:

La valeur en question serait vérifiée à tout les ... quoi.. 30 secondes ?
Donc une requête/30 sec / joueur en ligne de plus :-\

En plus de devoir toujours modifier 2 trucs de 2 tables différentes par changement. Donc le double de requêtes pour modifier des attribue d'une classe personnage.

[Haiken]

ne pas utiliser les sessions pour stocker des données dynamiques, qui peuvent bouger ; les bases de données, c'est fait pour ça !

La seule chose qu'on peut stocker en session, c'est ce qui n'est jamais modifié (login du joueur) ou alors très peu souvent et utilisé par une seule personne ou peu important (ex : le nom du joueur, ce n'est pas grave si c'est l'ancien qui est affiché tant que le joueur ne se reconnecte pas)

Si vous voulez accélérer les perfs, utilisez le cache de requêtes de MySQL ou à l'extrème un cache d'objet mémoire comme memcached ou ceux inclus avec les caches d'opcode (eaccelerator, apc, etc) mais en faisant très attention à la concurrence d'accès (les transactions n'ont pas été inventées pour rien)