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

[Caribou]

Salut à tous..

Bon en ce moment je suis dans les profils et edition, ça saoule un peu je perd du temps mais bon.

Je songe déjà au classement en faite depuis un moment, et je m'interroge sur la façon de faire j'ai un peu de mal à le concevoir in my brain.

Evidemment le plus simple c'est de faire des requetes mysql ORDER BY pour construire son classement, sur ce point ok.

Mais moi ce qui m'interesse c'est de faire un cache du classement, pour eviter des requetes en boucle par les users.

Faire un classement en temps réel, ça sent le roussi je trouve, probablement une des requetes les plus lourde qu'on puisse faire (en fonction du nombre de joueurs à classer evidemment)

Bref j'ai tout d'abord penser à une simple génération de pages html... mais j'ai vite déchanté, parce que ça rend peut etre les fonctions style recherche plus difficile à mettre en oeuvre..

Alors je repense au Cache MySQL, que je n'ai jamais utiliser, je me dis que ça pourrait être sympa mais y'a un probleme qui me turlupine, apparemment le cache sert uniquement dans le cas ou les données n'ont pas été mise à jour, une fois à jour, MySQL vide le cache et accepte à nouveau les requetes à executer.
Y aurait pas moyen de controler cette fonction ? par le biais d'un timestamp par exemple, pour lui faire comprendre qu'il doit se servir du cache pendant une demi-heure et qu'ensuite il peux l'effacer ?


Bon donc qu'est ce que vous en pensez du Cache MySQL? ou alors est-ce que c'est habituellement des pages généré ?
D'ailleurs peut etre que pour gerer les classements vous avez d'autres idées en tête ?
Ou peut etre que je me prend trop la tête et que je devais faire travailler MySQL plus souvent :glace:

[denisc]

En fait tout dépend du type de classement a mettre en oeuvre...

Si il doit être à jour en temps réel, il n'y a qu'une seule solution, c'est la requête... Celà dit, ne t'inquiète pas pour les ORDER BY, c'est effectué très rapidement par les SGBD. Au pire, tu perdra 1 ou 2 centièmes de secondes par millier d'utilisateur!

Si tes stats sont générées 1 ou 2 fois par jour, le mieux est de stocker le résultat de la requête en BD (une table cache par exemple, contenant un champ blob ou text) ou dans un fichier (moi j'utilise ce système pour la gestion de mon interface multilangues). Ce fichier ou cette mise en cache est régénéré dès qu'un de tes joueurs demande la page de stats et que la date d'expiration des stats précédentes a été atteinte. Dans le cas contraire, on retourne la valeur du cache de la BD ou on fait un include du fichier généré précédemment.

Si c'est pas clair, fait moi signe, je te ferai un petit dessin :p

[naholyr]

Le plus efficace c'est encore d'utiliser un cache de données.
Par exemple PEAR::Cache_Lite est performant et ne nécessite pas de config particulière côté serveur (contrairement à Memcache ou APC).

Code PHP :

<?php 

$cache = new Cache_Lite(array('cacheDir'=>'/path/to/cacheDir/', 'lifeTime'=>7200 /* 2h */));

if ( ! ($classement = $cache->get('classement')) ) {

  // Il n'y a rien dans le cache



  // ... Faire ici toutes les requêtes, les tris, les calculs, etc...

  // obtenir un tableau associatif avec tout le classement



  // Mettre en cache les données

  $cache->save($classement);

}



// Afficher les données du tableau $classement :) 

[denisc]

C'est donc le principe du cache par fichier.
Il existe d'autres classes de cache pour stocker en BD

[naholyr]

C'est tout l'intérêt des liens que j'ai fourni avec mon message, ils expliquent en introduction que tous les systèmes de cache par BD ont montré des performances moindre que les caches par fichier En même temps il faudrait comparer avec une table HEAP et des index, je ne sais pas quels systèmes ils ont comparé ce n'est pas expliqué

[Amrac]

Faut surtout voir si c'est adapté à la taille de ton site.

Mettre en place un système de cache est très contraignant puisque tu fait perdre de la qualité à ton jeu (classement à retardement) alors que le gain de ressource serveur est peu être négligeable.

Perso, sur mon site ça se fait en simple requete Order by sur une BDD de 4500 joueurs, j'ai aucun ralentissement.

[Loetheri]

Il faut aussi voir s'il y a un réel intérêt à faire un classement continu ou périodiquement ^^
Maintenant, je crois que l'on t'a montré différentes possibilités, c'est à toi de voir :p

[naholyr]

Tiens pour t'aider à savoir si tu dois ou non utiliser un système de cache, j'ai fait ce petit questionnaire qui couvre en gros le déroulement des questions à se poser. Avant de dire que tu n'as aucun intérêt à utiliser un système de cache il faut se poser plusieurs questions (et ce pour chaque page, voire chaque "portion de code") :


Source Graphviz (pour ceux qui ne connaissent pas il s'agit d'un générateur libre de diagrammes basé sur des fichiers sources, à ouvrir avec un éditeur de texte classique)

Donc à, moins que ton classement doive impérativement être à jour à moins d'une heure près, et que ta page "classement" soit visitée moins de 2 fois par heures, tu y gagneras

Après il est vrai que ça impose de revenir un peu sur son code, et si c'est un peu le bordel il peut parfois être difficile d'isoler des portions de code à mettre en cache.

[Mysterarts]

Ce diagramme ets très sympa ! Ca résume bien l'utilité d'un système de cache !
Et merci de m'avoir fait découvrir le générateur de diagramme, ça peut toujours servir.

Mysterarts

[Amrac]

Je ne suis pas d'accord, je pense qu'il manque deux paramétres à prendre en compte:

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?

A noter que si ton serveur n'est pas en manque de ressource, tu ne gagne rien à l'optimiser, tu as peu etre plus important a faire

Edit: Jolie diagramme