[sami_c]

#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: !1.8.x
#~ Url du site : http://tinyurl.com/3hovuek
#~ Hébergeur / Soft : OVH - Serveur RPS Gentoo
#~ Informations Système :
#~ Serveur RPS avec OS Gentoo
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Bonjour,
J'ai créé un site en Arabe, il s'agit d'un journal en ligne mis à jour très fréquemment dans la journée. Le site n'est pas encore lancé, donc pas trop de trafic. Les seuls utilisateurs sont les rédacteur qui ont saisir des centaines d'articles. Au début, quand le site contenait une dizaine d'articles il était un peut lent, maintenant avec les centaines d'articles le site est devenu trop lent : plus de 8 secondes pour 'affiche n'importe quelle page dynamique ! Le site exploite essentiellement le module News, il n'y a que très peu de modules (sondage, ...) J'ai analysé le site avec http://www.gtmetrix.com/ qui m'a conseillé, entre autres choses, de cacher les images, js et css, chose que j'ai pas compris comment intégrer sous CMS MS. Quelqu'un a une idée comment je peux corriger ça ?
Je pense maintenant à installer Varnish, mais je voudrais d'abord comprendre pourquoi le site est aussi lent !! CMS MS n'est pas fait pour ce genre de site ??
Merci

[bess]

200 OK aljarida.com.tn 9.2 KB 42.73s

issu de l'onglet timeline de Gtmetrix. C'est énorme en terme de temps pour tellement peu de poids transféré

cherche les erreurs ailleurs.

dans ton fichier de configuration tu actives la dernière ligne qui permet d'activer les stats SQL en bas de page.

préviens nous que l'on puisse regarder ensemble une fois les stats visible dans le code HTML de la page (ils seront cachés, pas de panique)

maintenant rien ne t'empêche d'améliorer effectivement le frontal en suivant les conseils de GTMetrix car ton site est bien trop lourd dans son ensemble (ça n'explique pas le problème principal)

regarde ces billets pour plus d'explication

http://www.cmsmadesimple.fr/blog/3/15/Le...Speed#main
http://www.cmsmadesimple.fr/blog/13/15/L...ccess#main

[sami_c]

j'ai dé-commenté la ligne suivante :
$config['show_performance_info'] = 'anything';

Je ne vois aucuns requete SQL ajouté à la fin, juste le commentaire HTML suivant :
<!-- 28.615392 / 2397 / 12738324 / 15759532 -->

j'ai fais quelques bidouille, on peut activer le mode "debug" en ajoutant &debug=1 (ou ?debug=1) :
http://tinyurl.com/jrdtndb

[sami_c]

j'ai compris le message de debug en commentaire :
Generated in 23.23841 seconds by CMS Made Simple using 2410 SQL queries and 13594412 bytes of memory (peak memory usage was 16824240)

Donc ma page a généré 2410 requêtes SQL !! insensé !!! dans ce cas ce n'est pas un proxy qui va résoudre le problème ! Comment je peux savoir le bout de code qui a provoqué ce grand nombre de requêtes sql !! ??

[bess]

Donc ma page a généré 2410 requêtes SQL !! insensé !!! dans ce cas ce n'est pas un proxy qui va résoudre le problème ! Comment je peux savoir le bout de code qui a provoqué ce grand nombre de requêtes sql !! ??

tu as le doigt sur ton soucis, je m'en doutais d'ailleurs :/

dans ton gabarit combien as tu d'appel à {News} ? tu as peut être été trop gourmand en terme de remontée d'information ? notamment avec les informations complémentaires :

Code :

FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '591' ORDER BY B.item_order

Debug: (0.924808) - (9757080)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '590' ORDER BY B.item_order

Debug: (0.932457) - (9764100)

Debug: (18.814808) - (16126764)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '102' ORDER BY B.item_order

Debug: (18.823829) - (16135896)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '101' ORDER BY B.item_order

Debug: (18.832658) - (16147872)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '100' ORDER BY B.item_order

Debug: (18.841496) - (16156472)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '99' ORDER BY B.item_order

Debug: (18.850422) - (16166532)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '96' ORDER BY B.item_order

Debug: (18.85953) - (16175964)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '97' ORDER BY B.item_order

Debug: (18.868431) - (16182220)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '94' ORDER BY B.item_order

Debug: (18.87724) - (16190628)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '119' ORDER BY B.item_order

Debug: (18.88602) - (16199036)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '93' ORDER BY B.item_order

Debug: (18.894865) - (16201816)

(mysql): SELECT A.value,B.id,B.name,B.type FROM cms_module_news_fieldvals A, cms_module_news_fielddefs B WHERE A.fielddef_id = B.id AND B.public = 1 AND A.news_id = '159' ORDER BY B.item_order

lis ce billet http://www.cmsmadesimple.fr/blog/16/15/R...imple#main

il te donnera peut être des pistes sur comment utiliser les données de {News} sans rentrer dans les travers des multi-multi-multi-requêtes

c'est juste une piste, absolument pas une certitude que ça résolve ton soucis.

[sami_c]

J'ai enfin pu réduire le nombre de requêtes : Le gabarit de la 1er page fait appel à plusieurs "Gabarits du sommaire article", il a a suffi de remplacer toute occurrence du genre :
{news summarytemplate="mon_gabarit_article" number="4" detailpage="details-news"}
par le contenu du gabarit en question pour que le nombre de requêtes tombe de 590 à 50 !!!

Pourquoi donc le fait de faire appel à ces gabarit génère un aussi grand nombre de requêtes !!

[bess]

d'après mes calculs tu devais avoir pas moins de 11 à 12 fois le code {news} dans ton gabarit, comme le module news ne gère pas de cache, à chaque appel tu te retape la totalité des requêtes sql.

pas d'idée de contournement là tout de suite maintenant...

ta solution si elle a le mérite de réduire immédiatement le nb de requête ne pourra pas être une solution définitive.

il faudrait plutôt réfléchir à faire un seul appel à {news}, foutre la liste des article dans une variable smarty ce qui peut être fait depuis un gabarit de news par défaut. On aurait donc

{news summarytemplate='mon_gabarit_a_appeler_une_seule_fois' number='4'}

avec à l'intérieur un truc du style

Code :

{assign var='itemsNews' value=$items}

Ensuite tu réduit à zéro ne nombre de news appelés dans tes autres block ce qui empêchera News de refaire des requêtes

{news summarytemplate='gabarit_slider' number='0'}
{news summarytemplate='gabarit_vignette' number='0'}

à l'intérieur de ces gabarit tu ajoutes en première ligne :

Code :

{assign var='items' value=$itemsNews}

Ainsi News devrait traiter normalement la liste des articles sans devoir recharger à chaque fois les entités.

Voilà une idée comme cela, bien évidement rien testé de mon côté. Dit moi si ça arrange tes affaires

[sami_c]

très intéressant comme idée cependant un seul appel du genre
{news summarytemplate='mon_gabarit_a_appeler_une_seule_fois' number='4'}
fait exploser le nombre de requête, en fait dans ma page j'en avait 4, chacune générait environ 500 requêtes, d'où le nombre phénoménale de 2000 requêtes !! Le plus bizarre c'est que j'ai complètement vidé le gabarit news "mon_gabarit_a_appeler_une_seule_fois" et le nombre de requête est resté le même ! Donc le problème est au niveau de l'appel d'un gabarit et non pas dans son contenu !

[bess]

ok je vois. J'imagine que tu as moult champs personnalisé ? tu gère combien de champs complémentaire pour les news ?

alors voilà une idée qui vaut ce qu'elle vaut : vu que News à l'air de faire des requêtes en séquentiel : passes toi de News pour le frontal et réalise ta propre requête sql avec des jointures (reprend mon exemple dans les liens que je t'ai filé)

tu connais les champs additionnels, ce sera aisé de réaliser une "super requête" qui irra tout récupérer en une seule requête (et non 1 + 499 supplémentaires sur les tables de champs additionnels). Tu peux également t'aider du mode debug pour observer les requêtes effectuées et la concaténer en une seule encore plus facilement.

une fois ta requête éprouvée sous phpmyadmin, tu fais une balise utilisateur dans laquelle tu fait ta requête en limitant aux 4 premiers résultat. Tu peux également jouer avec les paramètres d'entrée des UDT pour laisser cette limite de 4 être décidée par le paramètre de ton UDT : {monUdt limite=7}

ensuite toujours dans ton UDT tu créés un objet standard php qui contiendra ce que tu as remonté depuis la requête SQL :

Code :

$toto =  new stdclass();
$toto->date = ...
$toto->titre=
...
$toto->champsAdditionnel = ...

tu boucles afin d'ajouter successivement cet objet dans un array que tu repousses au final dans smarty

Code :

$smarty->assign('itemsNews', $la_super_liste);

tu ajoutes cet UDT en début de ton gabarit (genre avant le premier appel de {News}
tu supprimes de ton gabarit le premier appel de News : {news summarytemplate='mon_gabarit_a_appeler_une_seule_fois' number='4'}


et hop normalement les autres appels récupèreront ta super liste et l'utiliseront dans leur propre gabarit


Alors attention : la structure de ton objet doit être équivalent aux objets utilisés dans le gabarit, ça sera pas une partie de plaisir. Mais c'est certain ce sera plus performant.

J'ai déjà eu à faire face à ce genre de problème : la généricité absolue entraine bien trop souvent des soucis de performance. J'ai personnellement contourné le problème en gérant un mini cache interne dans mon module. Avant d'aller refaire une requête déjà effectuée, il pioche directement le résultat dans le cache. Ce n'est évidement pas parfait (quid d'une mise à jour de la donnée entre deux requêtes ?) mais les perf ont monté en flèche avec ce genre d'astuce.

[sami_c]

Merci pour la réponse rapide en fait actuellement j'ai réussi à réduire le temps de chargement en suivant le 1er lien que tu as proposé :
http://www.cmsmadesimple.fr/blog/16/15/R...imple#main

Je fais donc mes propres requêtes SQL et j'ai un temps de chargement d'une seconde
Cependant je bloque dans un truc : le clic sur un titre devrait afficher le détail de l'article, je n'ai pas pu trouver la bonne URL pour aller à la page Détail article ! Avec l'ancienne méthode (utiliser la balise {News}) j'ai des URL du genre :
http://.../index.php?mact=News,cntnt01,detail,0&cntnt01articleid=652&cntnt01returnid=32

Je n'ai pas compris l'utilité de ce "returnd" ni la provenance de sa valeur (32), car quand j'ouvre ce lien, les articles ont une nouvelle url :
http://.../index.php?mact=News,cntnt01,detail,0&cntnt01articleid=650&cntnt01origid=32&cntnt01returnid=29

Le returnid a changé (d'où vient ce 29 ??) et l'ancienne valeur est passé au paramètres origid !!!

Bref le tuto ci-dessous ne reprend pas un exemple de fiche détail, comment je peux le faire ?

[bess]

returnid est l'id de la page en cours

si tu génère un lien dans la page 4325 qui pointera vers la page 999 tu auras

http://.../index.php?mact=News,cntnt01,detail,0&cntnt01articleid=652&cntnt01returnid=4325

et si tu clic tu auras une nouvelle url :

http://.../index.php?mact=News,cntnt01,detail,0&cntnt01articleid=650&cntnt01origid=4325&cntnt01returnid=999

voilà pour l'explication de ces chiffres.

pour récupérer la valeur : utilise la variable globale xxxxx, disponible dans toutes les UDT de façon native.

edit pas celle là :/ 2s je recherche

[bess]

test un coup $returnid tout simplement voir s'il correspond à l'ID de la page courante ?

[bess]

heeyyy je viens de percuter sur un truc :

Version du CMS: !1.8.x

tu sais que si ça tombe vu l'ancienneté de ton site, les versions plus récentes ont déjà corrigé ce que l'on s’évertue à contourner depuis 5 jours ?????
commence par te mettre à jour :mad:

[sami_c]

en fait j'ai pas voulu mettre à jour pour ne pas à tout se retaper depuis le début ! Bon maintenant j'ai presque terminé, je vais planifier le maj pour plus tard.
Encore merci pour ton aide

[bess]

je vais planifier le maj pour plus tard.

je me répète : on doit surement réaliser actuellement ce que la mise à jour corrigerait toute seule.

commence donc par récupérer une copie en locale et claque la mise à jour par dessus.

sans chercher à avoir un site qui fonctionne à 100% tu auras au moins la certitude que le soucis reste/pars


et je n'aborderais pas ta responsabilité de laisser un site en ligne qui possède des failles de sécurité :/

[sami_c]

j'ai fais un upgrade vers la version 1.9.4.3 : rien n'a changé. J'ai toujours 2300 requêtes exécutées !!

[bess]

ok on reprend les hostilités..

peux tu réactiver le mode débug un coup ? voir précisément les requêtes restantes

[sami_c]

le débug est toujours activé : http://tinyurl.com/jrdtndb
avec la méthode indiqué ci-haut (utiliser une balise utilisateur avec du code PHP qui lance des requetes php) j'ai un temps de chargement d'une seconde, si j'utilise les balises {News} directement dans le gabarit, le temps de chargement est environ 3s, et avec l'ancienne méthode j'ai 24s !

[bess]

bon si le système te convient on peut s'arréter ici mais je ne m'explique pas vraiment ce qui peut t'arriver... à lire le code News faisait déjà des jointures SQL, donc je ne comprend pas d'ou viennent toutes ces requêtes

[bess]

c'est tout simplement allucinant... sur 150 requêtes restantes tu as 109 requêtes qui restent sur cms_module_news, cms_module_news_categories, cms_module_news_fieldvals ... bref pas mal de truc autour de News

je n'ai JAMAIS rencontré un tel phénomène :|

à la rigueur il faudrait me fournir un dump de ta base + un zip de ton site que je reproduise en local le phénomène

[sami_c]

je peux t'envoyer l'url des fichier par MP ou mail ?

[bess]

email : contact at cmsmadesimple point fr

[bess]

Premiers résultat de mon côté TRÈS encourageants :

Dans l'ordre des priorités ->

Te mettre à jour sur la production car la version 1.9.4.3 possède une surcouche de cache qui réduit les requêtes nécessaires. (tu m'as filé une 1.8.1 !!!) :mad: :mad: :mad: :mad:

Ajouter un champs number="10" dans les appels à {News} qui n'en ont pas déjà, Avant : > 2000 requêtes, après 500 requêtes

Mettre pour l'instant en commentaire le dernier appel : {news summarytemplate="bas_conten" detailpage="details-news"} car le gabarit est foireux, Je dois encore creuser de son côté mais même avec un number="0" il bouffe 400 requêtes à lui tout seul !!!!

Désactiver le mode débug de ton site

Dans config.php dé-commenter la dernière ligne #$config['show_performance_info'] = 'anything'; afin de suivre les évolutions de perf de façon plus discrète


Total de mes opérations : de +2000 requêtes je suis à 100 requêtes ce qui est déjà pas mal. Je continue de regarder le dernier point noir.

Remarque personnelle : vu le nombre impressionnant d'appel à {News} (6/7 ?) dans ton gabarit le nombre de 100 requêtes reste tout a faire compréhensible et peu compressible...

[bess]

La suite :

Mystère résolu : tu faisais appel à {News} dans le gabarit même de {News} ce qui provoquait une saloperie de boucle chargeant trop d'informations inutilement.

J'ai ouvert le gabarit de sommaire de news "list_categ_hp", j'ai tout copié à la place de

{news summarytemplate="list_categ_hp" detailpage="details-news"}

dans ton gabarit principal. Ensuite j'ai ajouter number="10" dans l'appel {News} et j'arrive à 141 requêtes.

Je regarde si d'autres gabarits comportent ce genre de trucs pas nets.

[bess]

bas_conten
bas_conten2
categorie
list_categ_hp2

sont les 4 gabarits de sommaires de news à posséder ce genre d'erreur. Corrige les en extrayant les balises {News} contenu dedans et ajoutant à celle ci une limite de taille avec number="XX". Utilise éventuellement des blocs de contenu globaux pour factoriser ton code et éviter que tes gabarits ne soient trop complexes


Autre axe d'amélioration : ton code est pourri de balise style="....". Je ne sais pas si tu en es l'auteur mais dans le milieu on appel cela une hérésie au même titre que IE6, ou l'utilisation des <table> pour faire du design (j'en ai vu passé d'ailleurs...)

ton code HTML n'est absolument pas valide, ça va forcement te jouer des sales tours.

Des emails trainent en clair, il faut les encrypter



Bref beaucoup de travail d'amélioration encore à faire avant de mettre ton site en production