10-11-2012, 01:00 PM
Pour ma part, j'avais le même genre de défaut de surcharge sur ECLERD. Une des solution au problème était effectivement de diminuer le nombre de requètes. Donc, une requète à 7 jointure était plus rapide que 7 requètes "simples", car le temps de connexion et de "mise en route" de SQL était non-négligeable face au temps de requète (imagine une requète lourde de 7ms+1ms le temps que SQL se mette en route, face à 7 requètes de 1ms de temps de requète +1ms le temps que SQL se mette en route, la requète lourde est plus rapide).
Egalement, tout ce que SQL sait faire doit être fait. S'il y a des calculs sur les colonnes à faire (somme, produits, max etc), des ordonnancement (groupes, ordres des résultats etc) alors il vaut mieux laisser SQL les faire plutôt que PHP (en tous cas, c'était bien plus rapide dans mon cas, un mutualisé perso chez OVH).
Pour le stockage quasi-statique, n'ayant pas les méthodes proposées par sephi, je me rabattais sur la génération d'une fichier PHP de constantes: la page d'admin PHP lit les données "semi-statiques" dans la BDD, puis enregistre ces données dans un fichier au format PHP, de la forme
<?php
define(<varname>, <var value>);
?>
Ce fichier PHP est ensuite utilisé par les pages web du jeu. Il est certainement possible de modifier légèrement ce système pour ne plus passer par la page d'admin et faire la regénération manuellement (par exemple, tu pourrai envisager d'enregistrer, dans le .php généré, la date de prochaine re-génération de ce fichier, et quand le fichier php du jeu récupère le php des semi-constantes, il vérifie la date de prochaine génération, et si elle est dépassé, il regénère le fichier tout comme le faisait la page d'amin). Cette méthode est assez redoutable, je trouve, pour tout ce qui est semi-constantes nombreuses (c'est vrai qu'une requète sur une table SQL de constantes, qui ferait moins de 20 lignes, ca dépote aussi tout à fait bien, mais si on a des requètes complexes, un système de fichier php pour les semi-constantes est un gain de temps).
Dernier élément: j'avais tendance à surmultiplier les requètes, ce qui est à éviter. Dans une première version, j'avais une boucle de 2000 tours, qui générait une requète pour récupérer toutes les informations d'une région du jeu... 2.000 requètes qui flinguent le serveur. Il vaut mieux, dans un tel cas, se prendre la tête pour ne plus faire "2.000 similations d'une région", mais "1 simulation d'un lot de 2.000 régions". Travailler par lots m'a permis de multiplier x100 la vitesse de simulation du jeu. Après, ceci n'est pas appliquable partout.
Elément-bonus: pour ma part, les données peu sensibles (en lecture-seule) mais récurrentes (nom du joueur par exemple), je les stocke dans des cookies chez le client: cela évite de faire des requètes serveur pour les lire, et si ces données sont peut sensibles, le fait que le client modifie les cookies n'influencera pas les autres joueurs. De même, certains traitements peuvent être fait chez le client via javascript, plutôt que chez le serveur (exemple: ordonnancement d'éléments, système de masquage/affichage des éléments d'une liste suivant, par exemple, des mots-clefs: s'il n'y a pas des tonnes d'éléments, je préfère tous les envoyer au client, et laisser le javascript faire les masquages/affichages hors-ligne, ce qui évite de recharger la page et de faire des requètes simplement parce que le client à décoché ou coché un tag).
Et je veux mon carambar.
Egalement, tout ce que SQL sait faire doit être fait. S'il y a des calculs sur les colonnes à faire (somme, produits, max etc), des ordonnancement (groupes, ordres des résultats etc) alors il vaut mieux laisser SQL les faire plutôt que PHP (en tous cas, c'était bien plus rapide dans mon cas, un mutualisé perso chez OVH).
Pour le stockage quasi-statique, n'ayant pas les méthodes proposées par sephi, je me rabattais sur la génération d'une fichier PHP de constantes: la page d'admin PHP lit les données "semi-statiques" dans la BDD, puis enregistre ces données dans un fichier au format PHP, de la forme
<?php
define(<varname>, <var value>);
?>
Ce fichier PHP est ensuite utilisé par les pages web du jeu. Il est certainement possible de modifier légèrement ce système pour ne plus passer par la page d'admin et faire la regénération manuellement (par exemple, tu pourrai envisager d'enregistrer, dans le .php généré, la date de prochaine re-génération de ce fichier, et quand le fichier php du jeu récupère le php des semi-constantes, il vérifie la date de prochaine génération, et si elle est dépassé, il regénère le fichier tout comme le faisait la page d'amin). Cette méthode est assez redoutable, je trouve, pour tout ce qui est semi-constantes nombreuses (c'est vrai qu'une requète sur une table SQL de constantes, qui ferait moins de 20 lignes, ca dépote aussi tout à fait bien, mais si on a des requètes complexes, un système de fichier php pour les semi-constantes est un gain de temps).
Dernier élément: j'avais tendance à surmultiplier les requètes, ce qui est à éviter. Dans une première version, j'avais une boucle de 2000 tours, qui générait une requète pour récupérer toutes les informations d'une région du jeu... 2.000 requètes qui flinguent le serveur. Il vaut mieux, dans un tel cas, se prendre la tête pour ne plus faire "2.000 similations d'une région", mais "1 simulation d'un lot de 2.000 régions". Travailler par lots m'a permis de multiplier x100 la vitesse de simulation du jeu. Après, ceci n'est pas appliquable partout.
Elément-bonus: pour ma part, les données peu sensibles (en lecture-seule) mais récurrentes (nom du joueur par exemple), je les stocke dans des cookies chez le client: cela évite de faire des requètes serveur pour les lire, et si ces données sont peut sensibles, le fait que le client modifie les cookies n'influencera pas les autres joueurs. De même, certains traitements peuvent être fait chez le client via javascript, plutôt que chez le serveur (exemple: ordonnancement d'éléments, système de masquage/affichage des éléments d'une liste suivant, par exemple, des mots-clefs: s'il n'y a pas des tonnes d'éléments, je préfère tous les envoyer au client, et laisser le javascript faire les masquages/affichages hors-ligne, ce qui évite de recharger la page et de faire des requètes simplement parce que le client à décoché ou coché un tag).
Et je veux mon carambar.