10-11-2012, 03:44 PM
(Modification du message : 10-11-2012, 03:46 PM par Sephi-Chan.)
(10-11-2012, 02:12 PM)Racktor a écrit :(10-11-2012, 11:06 AM)Sephi-Chan a écrit : Il faudrait voir la structure de ta base pour se prononcer sur les façons d'optimiser la structure.Je peux fournir le dictionnaires des données que je peux avoir avec phpmyadmin. Mais laisser à la vue de tous la structure de mes bdd, je sais pas si c'est bon niveau sécurité si quelqu'un de mal intentionné tombe dessus ...
Je ne vois pas trop ce qu'un utilisateur malveillant pourrait en faire. Il n'y a pas accès. À toi de voir mais tu peux aussi décrire ton modèle sur les points où tu as besoin de conseils.
(10-11-2012, 02:12 PM)Racktor a écrit :(10-11-2012, 11:06 AM)Sephi-Chan a écrit : Après, le grand principe quand tu développes une application, c'est la surveillance. En production, ce qui n'est pas surveillé n'existe pas. Tu devrais avoir des outils qui t'indiquent (grâce à des graphes) la charge de ta machine, l'utilisation de RAM, le nombre de requêtes au serveur Web, au serveur SQL, etc. Un exemple d'outil de ce type : Munin. Partant de là tu sauras comment se comporte ton système normalement, et tu seras de fait capable d'identifier un comportement anormal.Oui ca c'est vrai que ce que tu me décris est vraiment intéressant.
Juste une question sur l'utilisation :
je peux l'installer sur le serveur que j'ai chez power-heberg ou je dois faire ca en local ?
Tout au long de mon message, je considère que tu as accès à un serveur dédié. On ne peut pas héberger sainement une application sérieuse comme un jeu sur un serveur mutualisé.
C'est l'environnement de production qui est intéressant à monitorer, et ça implique que les outils de monitoring soient installés sur le serveur.
Ton hébergeur fait sans doute tourner les siens, mais je doute que tu y ai accès, et puis ça n'aurait aucun sens puisque la charge imposée n'est pas de ton ressort, mais également de celui de tous tes colocataires.
(10-11-2012, 02:12 PM)Racktor a écrit : je parle vraiment de données qui ne bougerais pas et donc pas fonction du joueur mais vraiment de ce qui est extrait de la Bdd
Dans ce cas, générer un fichier de constantes ou de variable peut être approprié. Tu peux utiliser la fonction
var_export
pour générer ce code.(10-11-2012, 02:12 PM)Racktor a écrit : Ca c'est pas mal, je ne savais pas que PHP pouvait stocker des données de cette façon.
Quand on parle de cache on parle de quoi exactement dans ce cas ?
On peut stocker beaucoup de données ?
C'est quoi les limites de ce système ?
Pour faire ça avec PHP, ça implique d'avoir APC (ou Memcache, ou Redis). À nouveau, ça nécessite généralement un serveur dédié.
Tout dépend de ce que tu appelles beaucoup. Les plus petits serveurs dédiés à 12€ TTC par mois (Dedibox SC et Kimsufi mKS 2G) disposent de 2 Go de RAM, autant dire qu'une bonne partie de ta base de données pourrait tenir dedans (surtout si tu as peu de texte, qui pèse lourd en comparaison de nombres).
Regarde le poids (en octets) de tes variables grâce à cette petite fonction, et tu verras que pas mal de choses peuvent tenir dans 1 Mo est déjà pas mal.
function variable_size($var) {
$start_memory = memory_get_usage();
$tmp = unserialize(serialize($var));
return memory_get_usage() - $start_memory;
}
Un cache, c'est un outil qui va te permettre de servir de tampon pour éviter d'aller interoger une autre source de données dont l'accès serait plus coûteux. Ainsi, on peut stoker des données comme des nombres, des tableaux, des objets, etc. Ça inclut des bouts de HTML complets !
Je t'en ai montré un échantillon avec la fonction que je t'ai montrée dans mon message précédent : si la fonction (imaginaire)
build_tech_tree
implique des tas de requêtes SQL et des calculs coûteux.On pourrait aussi imaginer les calculs d'une page pour afficher le classement : en créant une clé et en lui donnant un délai d'expiration (disons 10 minutes), on peut alléger considérablement les traitements d'une page coûteuse à générer.
La limite des caches sont généralement la présence de contenu spécifique à un utilisateur, puisqu'ils empêchent un élément d'être réutilisé pour tout le monde. Dans certains cas, utiliser un cache par utilisateur reste intéressant. C'est un calcul à faire.
Dans la même veine, on n'est pas obligé d'utiliser une expiration en temps, on peut expirer les caches manuellement.
Reprenons l'exemple de l'arbre technologique.
Tu souhaites afficher l'arbre d'un joueur spécifique (qui reprend l'arbre générique que j'ai mis en cache dans mon précédent exemple) dans lequel on met en évidence les choix fait par le joueurs (les technologies qu'il a développé, et jusqu'à quel niveau, par exemple).
Il suffit de lister les choix qu'à fait le joueur puis de stocker ça dans APC avec une clé propre aux joueurs (disons
players/1/tech_tree
) grâce à une fonction telle que je te l'ai montrée (qui retourne la valeur stockée en cache ou la calcul puis la stocke et la retourne si elle n'y est pas).Ensuite, tu pourras avoir une fonction qui accepte en argument l'arbre générique puis les choix d'un joueur et qui te produit le HTML pour afficher un bel arbre (ou une nouvelle structure que tu utiliseras pour générer le HTML).
Ensuite, lorsqu'un joueur développe une technologie, il suffit de supprimer la clé
players/1/tech_tree
du cache et il sera ainsi régénéré automatiquement au prochain affichage ! N'hésite pas à dire si tu ne comprends pas bien mes exemples ou ce que ça implique concrètement.Après, on n'est pas obligé d'utiliser la mémoire pour ça, on peut aussi utiliser des fichiers.
Même sans utiliser de framework complet, tu peux toujours utiliser le composant Zend Cache de Zend Framework. Ça permet d'avoir une API commune et robuste, avec différents back-ends (mémoire, fichiers, etc.).
(10-11-2012, 02:12 PM)Racktor a écrit : A la rigueur si ca peut m'encourager à utiliser un Framework, tant mieux.
Par contre comment le Framework résout ce genre de pb (on parle bien de la surcharge SQL) ?
Pas forcément la surcharge SQL directement, mais tout le nécessaire pour avoir des données statiques chargée une seule fois, pour garder certaines ressources en cache, pour produire des requêtes SQL efficaces, etc.
Les bons ORM (des librairies pour manipuler la base de données au travers d'objets), savent produire des requêtes avec jointures pour charger les données liées d'une traite.
Imagine un système de commentaires avec auteur. J'ai un modèle
Comment
(qui utilise la table comments
) qui dispose d'une colonne author_id
pour faire le lien avec un modèle User
(et sa table users
). Mon ORM me permet très facilement de récupérer des messages en y joignant l'auteur. D'ailleurs, dans la plupart des cas, l'ORM ne va pas faire une jointure mais va va charger d'abord les messages, puis récupérer toutes les valeurs author_id
, puis chercher tous les utilisateurs portant ces IDs et rattacher les objets User
aux commentaire appropriés.