Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1813 connectés 

  FORUM HardWare.fr
  Programmation
  PHP

  Mail de mon hébergeur : Surcharge sur le serveur, menace de coupure

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Mail de mon hébergeur : Surcharge sur le serveur, menace de coupure

n°2148992
Dawa
www.shootmeagain.com
Posté le 11-07-2012 à 13:07:41  profilanswer
 

Bonjour,  
 

Citation :

J'ai reçu hier ce mail de mon hébergeur web :  
 
Cher Monsieur  
 
Nous sommes obligés de vous communiquer, que votre hébergement pour le domaine:shootmeagain.com charge trop de ressources sur nos serveurs. Les raisons peuvent être différentes.  
 
Entre autres choses,  
composée des raisons suivantes :  
1. Trop de trafic cause d'une forte demande
2. Déficientes requètes de bases de  
données programmées
3. Excessive streaming des fichiers audio et vidéo  
 
L'hébergement Linux est basé sur le principe  
Shared-Hosting-Le client profite des conditions avantageux et peut délocaliser l'administration de l'infrastructure,  
au lieu d'utiliser son propre serveur Web. Ce principe constitue une utilisation appropriée de l'hébergement fourni  
aux clients Consciemment ou inconsciemment, cette règle n'est pas respecté dans quelques cas, malheureusement, cela  
cause un impact négatif aux hébergements d'autres clients.
 
Selon nos CGV le client est responsable de veiller ce que  
les scripts et les programmes du client placés sur le serveur de green ne soient pas entachés d'erreurs et ne soient  
pas d'un volume susceptible d'entraver les services de green;
 
Green.ch n'aucune obligation de vérifier que les  
contenus des offres du client sont conformes la loi. Green.ch se réserve le droit de résilier unilatéralement le  
contrat sans préavis et de déconnecter immédiatement les services concernés si elle apprend qu'une des infractions  
susmentionnées a été commise.
 
Nous vous demandons donc de prendre les mesures appropriées pour nettoyer votre site  
de web ou de migrer vers une plate-forme plus performante. A cet égard veuillez consulter notre offre green VServer  
(Serveur Virtuel), cet offre es plus performante pour vos besoins. Les détails pour l'offre vous trouvez sur le lien www.greenserver.ch.  
 
Nous vous laissons jusqu?au 16.07.12 14 :00 pour prendre les mesures nécessaires afin de résoudre le problème avec votre hébergement. Si passé ce délai , votre site  
continuerait générer ces charges extrêmement élevée, nous serions obligés de désactiver votre hébergement sur nos serveurs sans notification préalable.


 
 
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 !


---------------
SHOOT ME AGAIN WEBZINE
mood
Publicité
Posté le 11-07-2012 à 13:07:41  profilanswer
 

n°2149018
qfla
Posté le 11-07-2012 à 15:23:56  profilanswer
 

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


Message édité par qfla le 11-07-2012 à 15:24:03
n°2149030
aideinfo
Posté le 11-07-2012 à 16:06:52  profilanswer
 

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


---------------
http://www.aideinfo.com/  Whois adresses IP/domaines le plus évolué !!  FAQ Free Mobile
n°2149061
Dawa
www.shootmeagain.com
Posté le 11-07-2012 à 22:11:09  profilanswer
 

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 :??:

n°2149072
scvo0ne
Posté le 12-07-2012 à 00:03:58  profilanswer
 

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 ?
 
 

n°2149135
Dawa
www.shootmeagain.com
Posté le 12-07-2012 à 15:16:00  profilanswer
 

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  
 

Code :
  1. "select idinterview, slug, date, comment, texte, textevo, visits, interviewer, iduser, login, idband, bandname, url from interviews, groupe, users where interviews.band=groupe.idband and interviewer=iduser and idinterview=$id"


 
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 :  
 

Citation :

Voici cependant une légende explicative:
 
nbr.cmd nombre de commandes mysql par heure
 
nbr.con nombre de connexions mysql par heure
 
cmd/con moyenne de d'instructions par connexion mysql
 
longreq moyenne de longues requêtes par heure
 
 
Fair Use
nbr.cmd < 20000/h
nbr.con < 1000/h
cmd/con < 200/h wenn anz.con > 100/h  
longreq < 10/h
 
nbr.cmd nbr.con cmd/con slowqry domain  
21438 709 30 0 shootmeagain.com


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


---------------
SHOOT ME AGAIN WEBZINE
n°2149138
Dawa
www.shootmeagain.com
Posté le 12-07-2012 à 15:28:15  profilanswer
 

Ah, j'ai fouillé un peu la page "Etat du serveur" sur phpmyadmin et en effet apparement y a pas mal de couacs  :sweat:  
 
http://www.shootmeagain.com/stock/mysql01.png
 
http://www.shootmeagain.com/stock/mysql02.png
 
http://www.shootmeagain.com/stock/mysql03.png
 
http://www.shootmeagain.com/stock/mysql04.png
 
http://www.shootmeagain.com/stock/mysql05.png
 
http://www.shootmeagain.com/stock/mysql06.png
 
Bon, y a plus qu'à alors... par contre en 4 jours je vois pas comment je vais pouvoir régler tout ça :/


---------------
SHOOT ME AGAIN WEBZINE
n°2149139
Dawa
www.shootmeagain.com
Posté le 12-07-2012 à 15:28:55  profilanswer
 

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

n°2149174
dreameddea​th
Posté le 12-07-2012 à 20:52:06  profilanswer
 

Bonjour

Code :
  1. select idinterview, slug, date, comment, texte, textevo, visits, interviewer, iduser, login, idband, bandname, url from interviews, groupe, users where interviews.band=groupe.idband and interviewer=iduser and idinterview=$id


 
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

Code :
  1. select idinterview, slug, date, comment, texte, textevo, visits, interviewer, iduser, login, idband, bandname, url from interviews, groupe, users where interviews.band=groupe.idband and interviews.interviewer=users.iduser and interviews.idinterview=$id


 
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...

n°2149183
scvo0ne
Posté le 12-07-2012 à 22:16:12  profilanswer
 

"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.  
 

mood
Publicité
Posté le 12-07-2012 à 22:16:12  profilanswer
 

n°2149184
Dawa
www.shootmeagain.com
Posté le 12-07-2012 à 22:19:24  profilanswer
 

dreameddeath a écrit :

Bonjour

Code :
  1. select idinterview, slug, date, comment, texte, textevo, visits, interviewer, iduser, login, idband, bandname, url from interviews, groupe, users where interviews.band=groupe.idband and interviewer=iduser and idinterview=$id


 
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

Code :
  1. select idinterview, slug, date, comment, texte, textevo, visits, interviewer, iduser, login, idband, bandname, url from interviews, groupe, users where interviews.band=groupe.idband and interviews.interviewer=users.iduser and interviews.idinterview=$id


 
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...


 
 
Oui c'est bien juste :jap:
 
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 :o 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 !


Message édité par Dawa le 12-07-2012 à 22:20:34

---------------
SHOOT ME AGAIN WEBZINE
n°2149185
Dawa
www.shootmeagain.com
Posté le 12-07-2012 à 22:24:20  profilanswer
 

scvo0ne a écrit :

"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.  
 


 
Je n'avais AUCUN index avant maintenant :D 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 !


---------------
SHOOT ME AGAIN WEBZINE
n°2149380
Dawa
www.shootmeagain.com
Posté le 15-07-2012 à 07:49:09  profilanswer
 

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 !


---------------
SHOOT ME AGAIN WEBZINE
n°2149387
scvo0ne
Posté le 15-07-2012 à 11:44:46  profilanswer
 

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, ...).

n°2149415
Dawa
www.shootmeagain.com
Posté le 15-07-2012 à 21:05:59  profilanswer
 

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 !

n°2149480
Bynaris
Posté le 16-07-2012 à 13:44:26  profilanswer
 

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


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  PHP

  Mail de mon hébergeur : Surcharge sur le serveur, menace de coupure

 

Sujets relatifs
[Joomla 2.5] Composant qui gere les téléchargements par mail[powershell pour serveur]
Probleme de mail en HTMLfonction mail() ne fonctionne pas
[SQL Serveur] Restaurer un dump sans supprimer la réplicationLire un fichier sur serveur FTP
Java serveur, CASification et herbergementinteraction entre une application web mobile et un serveur LAMP
Envoyer vidéo youtube par mail (HTML)[1and1] envoi de mail
Plus de sujets relatifs à : Mail de mon hébergeur : Surcharge sur le serveur, menace de coupure


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR