PHP, les sessions et nos jeux.

[Amrac]

Bonsoir,
J'aimerais vous parler des sessions PHP, et surtout de leurs manque d'adaptabilité par rapport à nos jeux PHP.

La ou le bas blesse, c'est au niveau de l'optimisation de nos jeux.

L'optimisation est pour nous un point sensible, car le niveau d'optimisation de notre site influe directement sur l'argent que l'ont va devoir dépenser pour notre serveur.

Or, les sessions PHP on a mon gout des manques qui sont pourtant essentiels. J'aimerais, dans une session, pouvoir accéder aux sessions des autres joueurs et pouvoir les modifier.

Pourquoi?
Parceque ce serait une économie folle en ressource.
Je vais prendre un cas simple. Sur mon site web, j'affiche en haut a droite le nombre de nouveaux messages que le joueurs a. C'est à dire qu'a chaque page, je fait une requete exprés dans la BDD.
Ce simple affichage a produit rien que dans la journée d'hier 178 909 requêtes. :rip:
Or, (j'aime les Or en ce moment) il n'y as eu que 8 631 messages d'envoyé.
Si on pouvais, lors de l'envoie d'un message, parcourir la liste des sessions en cours sur le site, il suffirait de modifier le nombre de nouveaux messages que le joueur cible possède via sa session. Si aucune session ne correspond au joueur, alors on ne fait rien.


De la sorte, on remplace 178 909 requetes SQL par 8 631 éventuels modifications de session.

A noter que les sessions, en moyenne il doit y en avoir 50, et en heure de pointe ca grimpe à 200. La recherche d'une session est donc plutot simple (surtout que les sessions sont en rame, c'est donc rapide). Alors que pour le select, quelque soit le moment de la journée il faut le faire parmi 12 114 autres joueurs.

Je pense que vous imaginez un peu la taille de l'optimisation que ca représente.
Cela permettrais par exemple de réaliser certainnes choses jusqu'ici jugé trop couteuse, comme le fait de faire clignoter le lien "Alliance" lorsque quelqu'un a parler dans le chat d'alliance. (C'est un petit plus pour le joueur, mais ca renforce énormément la création de lien entre les joueurs, ce qui est le ciment de mon jeu).
Quand on ma proposer ca, dans ma tête le calcul était rapide: 178 909 requêtes en plus... Pas possible.

Or, il n'y as que 6 739 lignes d'entrées dans les chats d'alliance pour la journée d'hier.
Inutile de vous refaire le schéma, si on pouvait avoir 6 739 parcourt/modifications de session contre 178 909 requetes, ce serait génial!

Qu'en pensez vous? Quels sont vos impressions? Vos idées?

Ps: On remarquera que si on pouvait disposer de variables qui seraient globale a tout le site, notre problème serai résolus et nos sites serveur seraient heureux.

[NicoMSEvent]

éventuellement, tu pourrais modifier les varaibles de sessions si
1° tu les enregistre dans le répertoire temporaire (juste une ligne dans php.ini)
2° tu as accès en lecture/écriture à ce répertoire
3° tu as les connaissances en php pour le faire (ce dont je ne doute pas, c'était juste pour mettre un 3° ^^)

C'est un rien moins rapide que en ram (bien que avec le cache, ça ne devrait trop s'en ressentir)
ça a l'avantage aussi de ne plus passer par le sgbd

Une autre solution est d'envoyer une grosse requete qui récupère tout ce dont tu as besoin au début de ton script, plutot que d'envoyer 20 petites requetes qui vont récupérer a chaque fois une valeur. Maintenant, je ne connais pas la structure de ton site, et je ne sais pas si c'est possible

[Roworll]

Il est tout a fait possible de modifier les variables de session d'un autre joueur.
J'explique un peu comment je fais sur ce sujet

Pour résumer, tu peux charger la session d'un autre grâce à session_id(), faire des modifications à l'intérieur puis recharger ta session d'origine.

[Amrac]

Merci beaucoup Roworll, je trouve ton idée sur les sessions excellentes

J'aurais une question, il y a t'il une fonction pour charger une autre session?

[Zamentur]

tu peux charger la session d'un autre grâce à session_id()

[Roworll]

En gros, voila comment je procède.
Ce n'est pas mon code actuel, mais juste quelques lignes directrices.

Code PHP :

<?php 

//La session que je veux modifier existe-t-elle encore ?

if(file_exists(session_save_path().'sess_'.$lnJ['login_sess_id']){



    //Sauvegarde de l'Id de session en cours

    $mySess=session_id();

    //Fermeture de la session 

    //Cela permet d'être certain que toutes les informations 

    //sont enregistrées correctement

    session_write_close();



    //Chargement de la session du joueur qui m'intéresse

    //L'ID de session du joueur est enregistré lors de sa connection

    session_id($lnJ['login_sess_id']);



    //On démarre la nouvelle session

    session_start();



    //Quelques modifications

    $_SESSION['email']=1;



    //Fermeture propre de la session 

    session_write_close();



    //Récupération de la session du joueur actuel

    session_id($mySess);

    session_start();

} 

[uriak]

Donc l'idée serait à chaque mise à jour pouvant impacter des joueurs, de mettre à jour l'ensemble des sessions concernées, et d'économiser un rafraichissement de leur part à chaque chargement (ou sur une base chronogique)

De mon côté ce week end j'ai continué à réfléchir à mes soucis de session, et c'est vrai que renoncer aux économies d'appels SQL que me promettait l'usage des sessions pour garder la cohérence des infos me semblait fort triste.
Roworll connais-tu des défauts à cette technique ?

[joshua]

une bonne méthode je dirais consisterais a ne faire la verification que lors d'un insert. Comme ca tous les autres appels passent par la session.
Et moi j'ai une politique implacable en matiere de triche.
Première fois. Un message est envoyé. Deuxieme fois ,le compte est supprimé, que la triche ait fonctionné ou non.
Je n'ai pas de temps a perdre avec des gens qui n'ont rien de mieux a faire que de chercher les faiblesses d'un jeu pour en abuser....
Sauf si c'est a ma demande

[Roworll]

Modifier les variables de session n'a a mon sens pas véritablement de défaut (excepté le risque toujours présent de vol de session).

Par contre, il a des limitations.
Cela ne sert que pour enregistrer des informations volatiles qui ne dureront que le temps de la session. Ces informations volatiles peuvent au cas échéant devoir être sauvegardées en base de données.

Dans le cas d'une shoutbox d'alliance, à chaque message envoyé, on peut faire le tour des membres de l'alliance pour modifier leurs variables de session puis les notifier de l'arrivée d'un nouveau message. Pas besoin de sauvegarder les informations ailleurs. Si un joueur se déconnecte et se reconnecte plus tard, il n'a besoin d'aucune notification.

Dans le cas d'un message privé, c'est différent. On peut mettre à jour la variable de session pour notifier de l'arrivée d'un message, mais on doit aussi enregistrer cette information en BDD. A supposer que le joueur soit en ligne au moment de la réception du message mais qu'il ferme son navigateur sans aller le lire (et donc perde ses informations de session), il doit être prévenu de la présence d'un message en attente à sa prochaine connection.

Le degré de cohérence nécessaire varie en fonction de ce que l'on veut réaliser.

[Amrac]

J'adore ton système

Merci.