[Réglé] Classements, systeme de cache?

[naholyr]

Très intéressant, c'est justement sur ce point qu'on peut discuter :non:

Ton serveur est-il en manque de ressource? (Il faut déjà avoir un sacré jeu pour surpasser un serveur)

Faut-il vraiment attendre de manquer de ressources pour les économiser ? C'est presque une question d'écologie :ange:

Est -ce que le temps de développement nécessaire à mettre en place ce système de cache vaut vraiment ce que t'apporte le cache ?

Cela n'entre pas en compte à moins que ton développement soit vraiment crade il est excessivement simple d'encadrer une portion de code par un test, ou bien de remplacer un appel de fonction "$var = foo(...)" par "$var = $cache->call("foo", ...)"
Ce temps me semble négligeable.


P.S: ravi de vous avoir fait découvrir graphviz au passage, c'est un très bon soft :good:

[Loetheri]

Ton serveur est-il en manque de ressource? (Il faut déjà avoir un sacré jeu pour surpasser un serveur)

Est -ce que le temps de développement nécessaire à mettre en place ce système de cache vaut vraiment ce que t'apporte le cache?

S'il fallait attendre d'être en manque de ressources, ce serait con ^^
Tu vas coder comme un porc. Puis tu arrives à 75% de ton projet par exemple et ton code est tellement pourri que cela ralentit tout. Tu fais quoi ? Tu pries ? Non ... Tu optimises autant que tu le peux dès que tu le peux.

La deuxième question pourrait en avoir une autre qui n'est pas totalement juste je sais : Es-tu à ce point pressé pour ne pas développer une méthode qui aujourd'hui, te parait clair et que tu pourras aisément désactiver plus tard ou est-ce une charge supplémentaire que d'envisager l'avenir ?
En d'autres termes : FUTUR !

[Caribou]

Sympa le p'ti questionnaire

Je comprend ton point de vue Amrac, c'est un peu du style pourquoi réinventer la BDD vu que MySQL existe déjà, sur ce point je suis d'accord, mais je pense qu'il y a certaines répétitions de requètes qui serait bon d'éviter, et des requètes dispensable aussi.

MySQL utilisé massivement de partout sur son site, à mon sens c'est une erreur, mieux vaut faire le tri entre les requetes indispensable et dispensable.

Par exemple un systeme de messagerie privé entre joueurs, là je vais utiliser MySQL en temps réel pour la consultation du courrier (A la limite le cache MySQL pourra m'etre utile d'ailleurs je sais pas trop encore), donc je vais utiliser MySQL dans ce cas pour pas me prendre la tête car un cache de boites aux lettres c'est d'un tout autre gabarit que pour un classement.

Pour les stats ou classements, c'est sur que le serveur va pas mourrir si il est en temps réel (enfin je fais mes test sous free là... a mon avis ça explose meme tout seul dessus lol :toilette: ), c'est pas une requète complex, mais ce n'est pas indispensable non plus que ce soit en temps réel c'est surtout ça que je retiens. Alors je me dis tiens vu que là c'est pas vraiment indispensable d'interrogé MySQL à chaque fois, pourquoi ne pas faire un cache pour eviter les répétitions inutiles ?

Pour moi, le dev d'un jeu php en lui même est considéré quand même comme un dev web assez lourd (plus ou moins lourd en fonction des jeux evidemment), donc forcement si je dev quelque chose de lourd, je pense à l'optimisation.


Loetheri résume bien en tout cas, j'essaye de faire mon jeu en prenant en compte toutes les possibilités, c'est quand meme la base de la programmation si on y pense, et le fait que mon jeu puisse être saturé par un nombre de joueurs conséquent ou mon serveur ne suivant pas pour une qualité douteuse, sont des variables à prendre en compte, le fait d'allégér au maximum de mes possibilités ne peux être que bénéfique en terme d'avenir, en un mot l'optimisation c'est capital à mon sens.

Théorie d'une simple utilisation de MySQL avec des SELECT ORDER by (Sans cache MySQL) :
Un classement de 1000 ou 2000 ou meme 10000 joueurs, c'est pas vraiment ça mon souci, la requete sera executé rapidement.
Le problème c'est plutot au niveau activité, si je fais une requete mysql de classement de 10000joueurs par exemple, bon je connais pas les chiffres mais on va dire genre ca prend 0,01sec a MySQL pour traiter la requete, certes c'est rapide donc pas de problème.

Souci n°1, si je decide d'afficher la page suivante du classement -> nouvelle requete identique de classement.. à chaque fois je demande à MySQL de me classer 10000 joueurs, pour m'en afficher 50 ou 100, là déjà ya un souci non ? c'est comme demander à un imprimeur d'imprimé 10000affiches pour finalement en acheter que 100, on prend MySQL pour un con lol.

Souci n°2 (majeur!), si je navigue de pages en pages du classement comme ça parce que j'ai rien d'autres à foutre -> multiple requètes identique, et en supposant que le jeu marche bien et qu'il y a 49 autres mecs qui se font chier et qui naviguent aussi sur le classement -> multiple requètes identique x 50, rajoutons à cela que 250 autres joueurs voguent à d'autres occupations sur ton jeu -> multiple requètes identique x 50 + MySQL solicité ailleurs... resultat MySQL tourne à plein pot (ce qui ne veux pas dire qu'il explose, mais chaque chose a une limite).

Maintenant le même cas de figure, sauf l'utilisation d'un cache pour le classement, ca va alléger la charge MySQL de dizaines de requetes par seconde, ca va libéré MySQL pour les autres tâches ou ce dernier sera vraiment indispensable.

Au final tout ça repose sur la théorie comme quoi MySQL supporte difficilement les grosses charges pour aboutir à un too many connections si je me souviens bien, si demain on me dit que MySQL c'est trop de la bombe, zero risque que ca pete, ça traite 1,000,000 de requêtes par seconde, et ben vite les rêquetes en boucle :good:

[Amrac]

A vrai dire, vous avez raison :p

Cependant, la ou nos points de vue divergent, c'est que je trouve que le classement en temps réels à quelque chose de sympa, puisque ça permet au joueur de voir l'impact de chaque action (victoire, defaite ...) qu'il fait.

Mais en effet, si on vise plusieurs centaines de joueurs, mieux vos utiliser le cache
Vous m'avez convaincu

[Zamentur]

Souci n°1, si je decide d'afficher la page suivante du classement -> nouvelle requete identique de classement.. à chaque fois je demande à MySQL de me classer 10000 joueurs, pour m'en afficher 50 ou 100, là déjà ya un souci non ? c'est comme demander à un imprimeur d'imprimé 10000affiches pour finalement en acheter que 100, on prend MySQL pour un con lol.

Souci n°2 (majeur!), si je navigue de pages en pages du classement comme ça parce que j'ai rien d'autres à foutre -> multiple requètes identique, et en supposant que le jeu marche bien et qu'il y a 49 autres mecs qui se font chier et qui naviguent aussi sur le classement -> multiple requètes identique x 50, rajoutons à cela que 250 autres joueurs voguent à d'autres occupations sur ton jeu -> multiple requètes identique x 50 + MySQL solicité ailleurs... resultat MySQL tourne à plein pot (ce qui ne veux pas dire qu'il explose, mais chaque chose a une limite).

Je sui pas du tout d'accord avec çà...

Voici comment j'aurrais fait si il n'y a pas trop de classement:
Dans la table je creer une colone indexé pour chaque classement, on peut effectivement conciderer qu'un classement ce compte en point
Le nombre de point pour chaque classement du compte est modifié dés que le joueurs fait une action qui le modifie
Puis quand je desire obtenir le classement par exemple du 30eme au 60eme j'utilise tout betement ORDER BY classement LIMIT 30,60
Comme classement est indexé la requete ira tres vite a se faire car on ne fera que parcourir l'abre des indexs et mysql n'aurra aucun tris à faire...

Pour plus de precision sur cette methode: http://dev.mysql.com/doc/refman/5.0/fr/o...ation.html

A noter que les Index sont la plus importante des optimisations à faire dans un jeu (notament les jeux à grosse map(x,y) ou massivement multijoueur)
Sur une table de plus de 200 champs il peut etre interressant d'utiliser un/des index(s), pour determiner efficacement lesquel il suffit d'utiliser EXPLAIN

Ceci dit je ne remet pas en cause l'utilité d'un cache qui fera forcement gagné de la ressource sql, mais pas tant que çà!

[Caribou]

Je sui pas du tout d'accord avec çà...

Voici comment j'aurrais fait si il n'y a pas trop de classement:
Dans la table je creer une colone indexé pour chaque classement, on peut effectivement conciderer qu'un classement ce compte en point
Le nombre de point pour chaque classement du compte est modifié dés que le joueurs fait une action qui le modifie
Puis quand je desire obtenir le classement par exemple du 30eme au 60eme j'utilise tout betement ORDER BY classement LIMIT 30,60
Comme classement est indexé la requete ira tres vite a se faire car on ne fera que parcourir l'abre des indexs et mysql n'aurra aucun tris à faire...

Pour plus de precision sur cette methode: http://dev.mysql.com/doc/refman/5.0/fr/o...ation.html

A noter que les Index sont la plus importante des optimisations à faire dans un jeu (notament les jeux à grosse map(x,y) ou massivement multijoueur)
Sur une table de plus de 200 champs il peut etre interressant d'utiliser un/des index(s), pour determiner efficacement lesquel il suffit d'utiliser EXPLAIN

Ceci dit je ne remet pas en cause l'utilité d'un cache qui fera forcement gagné de la ressource sql, mais pas tant que çà!

Ben justement je me demandais si il y avait moyen de faire ça, je connaissais pas, c'est cool meme pas besoin de poser la question que j'ai la réponse :good:
En effet en indexé ça facilite à fond c'est indispensable, merci