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

[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: