Bonjour,  
 

 
 
Déjà je trouve ça un peu gonflé vu que je suis client chez eux depuis 6 ans, qu'il s'agit du premier avertissement et qu'ils me laissent 5 jours de délai pour régler ça.
 
Mais bon, si effectivement certains de mes scripts posent problème je suis prêt à les améliorer... mais c'est là que je coince, comment savoir ce qui consomme beaucoup de ressources justement ?  
 
Merci !

Utilise des outils d'analyse comme Firebug ou Google Chorme. Sinon tu as Speed Tracer de Google qui est pas mal du tout.

Visiblement, trop de fichiers vidéo/audio, et des requêtes SQL mal faites. Commence par revoir tes requêtes.

Mais vaut mieux plusieurs de requêtes légères ou une paire de requêtes vraiment beton pour limiter le nombre d'accès à la DB

Déjà faudrait savoir quel est le problème exactement ( trafic, script qui consomme trop de cpu et requête mal optimisée c'est pas exactement la même chose ). Demandes plus de précision à ton hébergeur, ca coûte rien et ca te dira ou chercher.
 
Sinon quelques pistes :
 
Y a quelques recommandations Google Pagespeed à suivre ( https://developers.google.com/speed [...] bile=false ). La compression Gzip diminuera la quantité de données transférée sans réellement consommer du cpu.  
 
Tu utilises la version non minifiée de jquery (ouch!). Tes autres js pourraient aussi être minifiés. Tes utilisateurs sans grosse connexion te diront merci.  
 
Il y a aussi quelques erreurs 404 ( ex http://www.shootmeagain.com/css/jq [...] v2.3.1.css )
 
Pour les requêtes, as tu accès au slow query log et à la config de mysql ? Est ce que tu as des index ou il faut ? Pas de join sans index ? Tu as un accès ssh, et si oui as tu déjà testé des scripts comme mysqltuner.pl ?
 
Tes stats analytics sont stables ou as tu plus de visites ces derniers temps ?
 
Quant à ta question sur les requêtes : l'idéal c'est de limiter le nombre de requêtes. Un exemple, j'ai cherché un artiste qui s'appelle % . La page met plusieurs secondes à s'afficher... combien de requêtes ont été exécutées ?
 
 

Hello !  
 
Merci à tous pour vos réponses et spécialement à scvo0ne pour ses précieux conseils.
 
Effectivement j'utilise la version "classique" de jquery, si tu penses que l'autre est moins lourde je vais me renseigner... elle a des inconvénients par contre je suppose ?  
 
Les erreurs 404, je vais checker tout ça. Tu es tombé sur celle-ci par hasard ou il y a un tool pour checker tout ça automatiquement ?  
 
Je n'ai pas spécialement plus de visites ces quelques derniers temps, c'est plutôt stable je dirais.
 
Pour les index, je pense avoir fait tout plus ou moins proprement... mes join en fait, je fais juste le lien entre les tables dans ma requête mysql, genre  
 

 
Et là en l'occurence, les champs qui lient les tables entre elles sont soit en "PRIMARY" soit en "INDEX"... il y a autre chose à faire ? Je ne suis pas vraiment expert en mysql, et j'ai appris complètement sur le tas, au fur et à mesure que mon site se construisait. Donc j'ai peut-être sauté un truc élémentaire...  
 
Mais après réponse de l'hébergeur, il se trouve que c'est au niveau du nombre de commandes mysql que ça pose souci :  
 

 
Donc ils considèrent comme "fair use" jusqu'à 20000 commandes par heures et je suis à 21438. Pas beaucoup plus, en fait...

Ah, j'ai fouillé un peu la page "Etat du serveur" sur phpmyadmin et en effet apparement y a pas mal de couacs    
 

 

 

 

 

 

 
Bon, y a plus qu'à alors... par contre en 4 jours je vois pas comment je vais pouvoir régler tout ça

"Fermer toutes les tables" et "Vider le cache des requêtes" ça sert à quelque chose ?

Bonjour

 
Pour faciliter la lecture des jointure, je préfère mettre le nom de la table devant la colonne...
 
Je réécris la requête avec les tables "explicite" tel que je le comprend

 
Donc tu as un index (ou primary key) sur :
iterviews.band ==> probablement pas nécessaire
groupe.idband
interviews.idinterview
users.iduser
 
C'est ça ?
 
Dans le monde oracle, il y a "EXPLAIN PLAN" pour savoir comment une requête est exécutée, je pense que dans le monde MySQL il y l'équivalent...
 
Sinon, pour information, tu as combien de requête différentes dans ton site ? Si il n'y en a pas trop tu peux faire l'équivalent d'explain plan pour chaque requête...
 
Bon courage...

"Fermer toutes les tables" et "Vider le cache des requêtes""Fermer toutes les tables" et "Vider le cache des requêtes" , dans ton cas ca ne servira pas à grand chose...
 
Pour jquery, la version minified est la même que l'autre, sauf qu'elle a été optimisée pour réduire sa taille ( nom des fonctions et des variables raccourcis, plus de commentaires/tabulations/retour à la ligne..). En principe la version "classique" ne doit être utilisée que pour pouvoir lire / étudier le code, et la version minifiée doit être utilisée sur les sites en productions.  
 
Pour les 404, juste firebug... En règle générale je m'en sors avec firebug et les logs d'apache  
 
Pour les indexes, visiblement tu as compris le truc mais il doit en manquer quelque part. Donc soit tu vérifies les tables et les requêtes une par une en utilisant EXPLAIN, soit tu prend ton serveur de test, tu actives log-queries-not-using-indexes, slow_query_log, tu met une valeur faible ( 1 seconde) pour long_query_time et tu surfes sur ton site de test comme le ferait un visiteur tout en surveillant tes logs.
 
Maintenant pour en revenir à ton problème vis à vis de ton hébergeur (et l'urgence est là, le reste peut attendre quelques jours) , y a pas 36 solutions, soit tu as des requêtes dans des boucles que tu peux optimiser, soit tu met en place un système de cache, soit tu changes d'offre / d'hébergeur.  
 

 
 
Oui c'est bien juste
 
Et c'est vrai que c'est plus lisible, je n'ai simplement jamais pris le temps de réécrire.
 
En fait (ne me frappez pas), je n'avais aucun index sur mes tables à part mes primary keys Mais je viens d'arranger tout ça et d'indexer tout ce qui doit l'être, en principe pas trop.  
 
Je viens également de découvrir le EXPLAIN, qui existe bel et bien en mysql. Et faire un EXPLAIN sur chaque requête, c'est le mieux à faire mais j'en ai beaucoup, à vue de nez 200 ou 300...  
 
Je vais me focaliser sur les pages les plus fréquentées, et consulter le query_log, pour gagner rapidement en nombre de requêtes puisque c'est ça qui pose problème...  
 
Merci en tout cas !

 
Je n'avais AUCUN index avant maintenant J'ai effectivement compris le truc mais c'est tout frais là donc je viens juste d'adapter tout ça. Ca va sans doute alléger le bazar mais ça ne va rien changer au nombre de requêtes évidemment.  
 
J'ai bien commencé à creuser mon query_log mais je ne connaissais pas du tout log-queries-not-using-indexes, je vais suivre tes consignes avec soin, et rapidement de préférence. Il y a quelques requêtes pas optimisées et répétitives donc je vais simplement faire quelques adaptations dans ma DB et dans les requêtes pour limiter les accès...  
 
Merci beaucoup !

C'est sans doute difficile à dire comme ça, mais en moyenne l'affichage d'une page "classique" est censée peser combien de requêtes vers la DB ?
 
Je viens de checker un peu et  c'est vrai que par exemple cette page : http://www.shootmeagain.com/chroni [...] lddieyoung
 
demande 21 requêtes mysql et ça me semble effectivement beaucoup. La barre de droite (avec tous les liens vers les dernières màj) en demandent déjà 5, il y a un compteur pour la page, etc. etc.  
 
Ca pourrait venir de là ?  
 
Merci !

21 requêtes pour cette page ca me paraît un poil élevé... Si tu dis que la sidebar en prend 5, il en reste 16 pour le contenu.
 
Est ce que pour le menu en haut de page et les liens en bas tu fais des requêtes ?
 
Un truc que tu pourrai faire serait de mettre en cache dans un fichier la partie de la sidebar qui change peu (concours, à la une, ...).

Je vais les analyser une par une, c'est vrai qu'il y a surement moyen d'en gagner quelques-unes assez facilement.
 
Par contre ça me semble être une excellente idée de stocker certaines données dans des fichiers, je n'avais jamais envisagé cette possibilité.  
 
Merci, encore une fois !

Surtout que pour la sidebar, tu n'auras besoin que du texte et du lien (et éventuellement d'une description).