Bonjour à tou-te-s,
Je bosse sur un gros site avec environ 1 million de forums.
Celà nous amène à atteindre certaines limites.
Notamment sur cette boucle:
<BOUCLE_comms(FORUMS){plat}{0,6}>
var_mode=debug m'indique un temps de calcul de 6.7 secondes et
l'intégralité des rows examinées (soit près d'un million donc)
On est sur un serveur puissant, mais quand je mets la boucle en prod,
sous l'affluence, le serveur freeze. (le squelette "les derniers
commentaires" qui la contient a un cache de 10 minutes, mais il est
probablement invalidé à chaque fois qu'un nouveau forum est posté).
Quelqu'un a-t'il eu le cas d'un gros site avec autant de commentaires?
Comment optimiser?
Des idées?
A+
Mathieu
Mathieu LOPES a écrit :
Bonjour à tou-te-s,
Je bosse sur un gros site avec environ 1 million de forums.
Celà nous amène à atteindre certaines limites.
Notamment sur cette boucle:
<BOUCLE_comms(FORUMS){plat}{0,6}>
var_mode=debug m'indique un temps de calcul de 6.7 secondes et
l'intégralité des rows examinées (soit près d'un million donc)
On est sur un serveur puissant, mais quand je mets la boucle en prod,
sous l'affluence, le serveur freeze. (le squelette "les derniers
commentaires" qui la contient a un cache de 10 minutes, mais il est
probablement invalidé à chaque fois qu'un nouveau forum est posté).
Quelqu'un a-t'il eu le cas d'un gros site avec autant de commentaires?
Comment optimiser?
Des idées?
regarde plus précisément quelle requete prend du temps avec var_profile=mysql
est-ce parce qu'il y a trop de requetes ou est-ce un probleme de critères ?
j'imagine que tu n'affiches pas ton million de message sur une page, il y a donc sans doute moyen d'optimiser...
@++
regarde plus précisément quelle requete prend du temps avec
var_profile=mysql
est-ce parce qu'il y a trop de requetes ou est-ce un probleme de critères ?
j'imagine que tu n'affiches pas ton million de message sur une page, il
y a donc sans doute moyen d'optimiser...
@++
J'avais bien fait ça, et c'est bien la requete de la boucle forum !par
id_forum, avec un limit 0,6 qui posait problème.
La raison de cette lenteur: le critère WHERE statut='publie' (qui a
moins d'impact quand on sélectionne sur id_article, id_thread,etc,
puisque celà ne trie pas sur le million de forum que j'ai à gérer)...
La solution que j'ai mise en oeuvre une vue sans le statut:
$query="SELECT id_forum FROM spip_forum ORDER BY id_forum DESC LIMIT
0,30";
sql_create_view('spip_fast_forum',$query);
Que j'utilise dans les squelettes comme ça:
<BOUCLE_comms(SPIP_FAST_FORUM){!par id_forum}{0,6}>
<INCLURE{fond=inc-item-forum}{id_forum=#ID_FORUM}>
</BOUCLE_comms>
Si un forum n'a pas le statut publié, le sous_squelette inc-item-forum
(qui contient une boucle forum qui sélectionne donc un unique forum par son id_forum) n'affiche rien.
Je passe de 6.3 secondes à 0.00124605702209 :
Mon serveur apprécie et moi aussi 
A+