Bonjour
J'expérimente depuis quelques temps des lenteurs imprévisibles et/ou lors du login. Ce phénomène semble du à deux choses.
La première, vient tout bêtement du cadre logiciel que je me suis donné d'un côté pour mettre au point refra.fr, (cf. drupal) et qui s'appuie sur de très nombreux accès à une base de donnée "mutualisée"; il s'avère que cette base de donnée est située sur des serveurs "partagés" et qu'en gros, lorsqu'on est aux heures de pointe, ces serveurs de base de donnée mutualisés sont tellement saturés qu'il rament. Un utilisateur "anonyme" qui ne se loggue pas utilise la base en consultation seule, et les données de cette base étant intouchés, restent donc préférentiellement "en cache" ce qui en rend probablement l'usage plus rapide. Du moins, je crois. Cependant à partir du moment où vous vous logguez, pour rajouter du contenu qui donc ne peut être en cache, vous accédez plus directement à la base elle-même et pas au cache. Et là, on sent une différence. En heure de pointe, la base est tellement saturée de requêtes que j'attends deux minutes pour que la requête d'administration fasse retour ! Idem pour les ajouts / modifs de commentaires. Juste pas possible !
On peut dire merci à OVH (mon hébergement mutualisé).
La seconde, ce sont ces p... de robots ! Afin d'être référencé sur google, je ne peux pas les empêcher de passer sur le site. Or, certains d'entre eux produisent plusieurs milliers d'accès en quelques secondes et saturent inutilement www.refra.fr de demandes. Il semble en outre que certains robots spécifiquement utilisés par des spammeurs de forum aient une espèce de manie de flooder la base et les événements système. Bien que j'aie mis en place quelques mesures anti-flood, et que j'essaie d'opérer préventivement à des blocages de comptes d'utilisateurs qui créent leurs profil avec des robots ou utilisent une adresse mail de confirmation truffée de termes anglais interdits ne laissant aucun doute sur leurs interventions à venir, .., le caractère "agressif" des requêtes préparatoires des spammeurs "noie" le site et je me retrouve régulièrement coincé lors du log au cours d'une requête vers la base de donnée qui ne répond pas.
Je suis donc en train de chercher des solutions, de tous les côtés, du côté de mon hébergeur, et du côté de l'optimisation du site.
Je n'ai logiquement pas pu répondre systématiquement à tout le monde ni écouter tout ce que je voulais, je m'en excuse, mais il me semble que ce genre de problème doive être réglé en priorité.
Minimiser les accès à la base de données est à mon avis le premier axe de travail à mettre en chantier immédiatement.
Chaque événement système, même le plus anodin comme par exemple une adresse ip visitant le site, crée un événement système, et alimente des statistiques, elles-mêmes re-stockées dans la même base de donnée.
Mais n'est-ce pas justement complètement inutile d'enregistrer les événements système dans la base de donnée ? Pourquoi ne pas les mettre dans un fichier, type syslog ? Allez, zou c'est fait.
Si j'avais à peu près 10000 visites par jour, et des centaines de connexions simultanées, j'aurais de sérieux problèmes, avec ma base de donnée mutualisée car chaque visiteur en plus d'ajouter des nouveaux événements systèmes, met en action un module "statistique" qui crée des multiples accès supplémentaires à la base de donnée pour y stocker des jolies stats ; donc certes "ça marche" mais aïe qu'est-ce que c'est relou... ; le plus stupide dans cette affaire c'est que les visiteurs les plus actifs sont ces pu... de robots, qu'ils soient des robots de moteurs de recherche ou des robots de spammeurs ; ces robots produisent des milliers d'accès à la base de donnée, lors de leur passage : ça correspond à un petit ourangan invisible et l'effet est très simple : le surf pédale dans le yahourt, grave.
Pour couronner le tout, drupal (le framework de travail de départ) est réputé pour créer beaucoup d'accès base de donnée (même trop pour certains) et, pas mal de professionnel du développement web admettent que s'il est très intéressant et très flexible, son module statistique "interne" a un impact catastrophiquement lourd dur la performance globale ; donc, si nécessaire, je vais plutôt m'appuyer sur un module d'analyse de trafic externe du type "google analytics", ce qui "déleste" ma base de donnée du boulot nécessaire de devoir stocker les stats - stats qui, franchement, ne sont pas fondamentales, dans la mesure où la quantité d'utilisateur et de visiteurs par jour est trop restreinte pour en avoir réellement besoin.
Enfin, la cession ; par défaut, une fois l'utilisateur loggué, il conserve sa session et son cookie de connexion ok, dont la durée de vie est quasi illimitée. Or, ça me pose un problème, surtout quand on est en mode "bande passante de merde en heure de pointe" ; un utilisateur qui s'est déconnecté, est mieux loti que celui qui a gardé sa session active ; en effet un visiteur utilise le cache qui est performant et très rapide, tandis que l'utilisateur loggué ne l'utilise pas ; j'aimerais donc au moins qu'un utilisateur enregistré qui a fermé son navigateur/onglet de surf, et qui retourne sur le site en heure de pointe, puisse juste "lire" le contenu du site et pas tomber sur une page blanche qui tourne à vide. Donc supprimer le cookie quand l'utilisateur enregistré ferme l'onglet ou le navigateur, c'est un bon moyen de s'assurer qu'il bénéficie par défaut du système de cache - relativement performant - dans un premier temps. Donc si vous constatez que vos cessions expirent systématiquement : c'est normal, mettez ça sur le compte des optimisations nécessaires.
L'Administrateur
Wow, ça sent le pâté.
Je m'acharne à croire que mes lenteurs viennent de mes scripts. Visiblement, c'est plus profond. Je fais quelques tests ce matin en connexion FTP : aïe, ça plante. Ca sent très mauvais. La connexion FTP, ça contacte les fichiers de mon site en prise directe sur le serveur où il est hébergé. Et si je n'arrive pas à naviguer non plus sur l'interface FTP, ça veut dire que les lenteurs j'y peux rien, en fait, et que tout était dans les mains d'OVH depuis le début.
Je cherche, je cherche et je trouve : ce fil de discussion sur la baisse de qualité de service de l'hébergement mutualisé chez OVH : consternant ! Le fil traine depuis des mois et OVH peine juste à entretenir l'espoir d'une amélioration à coup de rustines, et de scotch, (métaphore) sur une infrastructure à genoux ; la com de l'hebergeur est timide, inexistante, et quand elle intervient, c'est pour donner le change ou botter en touche ; OVH annonce des plans de travaux, les consigne sur un tableau de bord temps réel qui donne une image 'rassurante" comme quoi ça bosse, fait miroiter des améliorations à venir, mais la ficelle ne vaut que si et seulement si le résultat observable suit derrière ; car pour les grandes modifications structurelles, pas de dates, pas de délais.
Ca parle de travaux en cours, à venir, et d'améliorations, de réparations, de problèmes identifiés et réparés, pour deux ou trois jours, problèmes qui repartent de plus belle, bref, ça donne le change, pour pas changer grand chose pendant des semaines.
Après un petit tour sur mon profil client, je viens de m'aperçevoir qu'OVH m'a royalement casé sur le "cluster006" le plus souvent cité comme merdique par les intervenants. J'ai justement choisi OVH parce que tous mes potes en parlaient jadis et louaient la fiabilité du service. Visiblement, cette époque semble révolue.
L'infrastructure d'hébergement mutualisée, aurait, semble-t-il, rencontré des problèmes d'équilibrage suite à l'arrivée massive de profils de sites trop gourmands, mais qui, ont été indubitablement attirés par le package commercial d'OVH en amont (la notion de trafic illimité et toujours plus de gigas octets à disposition, auront fini par attirer les sites de "gros stockeurs" et in extenso les "gros téléchargeurs", qui monopolisent les serveurs et impliquent des délais d'attente trop longs pour les myriades d'autres "petits sites") .
La notion de "mutualisation" des ressources est visiblement problématique, je n'y connais rien en la matière, mais pour résumer : OVH a merdé quelque part, si c'est pas au niveau du dimensionnement de l'offre par rapport à la nature de sa propre infrastructure, c'est au niveau d'une bidouille supposée améliorer les performences, qui a eu l'effet inverse et a complètement déstabilisé la mutualisation ; en clair, OVH ne peut revenir en arrière ; les interventions tantôt ironiques, tantôt désespérées des clients qui ouvertement déclarent se barrer suite à un niveau de résolution très mauvais, à la perte de 90% de leurs visiteurs au fil de la journée, juste pour sauver leur chiffre d'affaire en chute libre ; ... et la couille est visiblement toujours en train de flotter dans le potage. J'envoie un mail à leur support : ça me le renvoie direct en disant que ce mail ne fonctionne plus. Et qu'il faut aller sur le site. Je vais sur le site, ça me renvoie à un bouton qui dit qu'il faut ouvrir un ticket. Je clique sur le bouton ticket, ça me dit que si je dérange les tech pour un truc qui concerne le réseau c'est gratos sinon ça me coute 20E. Vu que ma bande passante est bloquée une fois sur deux, j'ai une chance sur deux qu'ils me disent que leur réseau & mon site fonctionnent très bien et me chargent de 20E (le diag est probablement ponctuel, effectué à un temps t, et pas établi sur le long terme). Vais-je la jouer comme au poker ou au casino online ? Et prendre "le risque" de claquer 20E pour obtenir une réponse à la con que je flaire d'avance ?
C'est surtout que ce genre de question, si j'avais vraiment confiance, je ne devrais même pas me la poser.
...
lapiNIC
C'est bon j'en peux plus, je dois m'y reprendre à quatre fois pour poster un message, après avoir relancé sans sans arrêt la fenêtre d'édition.
Bon, vous savez quoi ?
On va se casser de chez OVH les enfants.
Dans l'attente, et je m'excuse pour vous recommander ça, mais je vous invite à surfer sur ce site et à poster vos contributions plus tard le soir, à partir de 22h, 22h30, en dehors des heures de pointe, en espérant que tous les utilisateurs du réseau OVH n'aient pas exactement la même idée.
Je modifie l'a page d'accueil en conséquence et je cherche une solution pour rappatrier mon site ailleurs...
Merci pour votre (grande) patience.
L'Administrateur
J'y crois plus trop aux hébergements mutualisés.
Je vois qu'Infomaniak propose des solutions de rappatriement ;
Je ne me fais pas d'illusions, c'est pas forcément plus fiable.
Mais on va dire que ça peut pas être pire.
Cependant ce rappatriement doit être fait 6 mois après l'acquisition du nom de domaine.
Ahgh, ça ne sera possibles qu'à partir du 19 mars 2013...
@####@@ !
Faut attendre encore 14 jours ! Une éternité !
L'Administrateur
Bon donc je mets en place un compte à rebours.
Je n'ai quasiment plus de visiteurs/utilisateurs actifs aujourd'hui.
C'est simple si le 20 mars 2013 la situation ne s'est pas améliorée nettement je migre vers un hébergement alternatif, point.
J'ai pas de problèmes, j'ai que des solutions.
L'Administrateur
ah le ticket technique ouvert chez OVH la semaine dernière été ouvert
quelle coïncidence, le tech découvre que tout marche bien.
je retourne sur www.refra.fr
en effet, tout marche bien
...
ben voyons
...
je regarde les logs des travaux en cours et achevés : la veille ils ont juste réparé un disque défecteux, propagé un script de régulation des ressources réseaux, et remis en état une dizaines de serveurs mysql qui foiraient sans arrêt, pour sûr que ça marche mieux aujourd'hui.
ils sont marrants, ils réparent, ouvrent les tickets, et font comme s'il n'y avait jamais eu de problème
...
mais bon, je ne vends pas la peau de l'ours : je veux pas d'une rustine ou d'un bout de scotch qui va se décoller au bout d'une semiane : ça doit tenir.
Je surveille et je reste vigilant.
L'Administrateur
vas y camarade fais y fumer
ouais bah j'ai bien fait de surveiller et de rester vigilant, ça a pas tenu deux jours.
ce que je n'apprécie pas, c'est la foutaise de la démarche diagnostique .
(1) juste avant le diag de le tech réseau ovh, il placent les ressources du site en haute priorité donc la réponse du site est ok ; plus de lenteurs, plus de plantages, etc...
(2) le tech arrive, comme par hasard il teste il trouve qu'il y a pas de problème; comme si ça venait de mon code ou de mes scripts;
(3) le tech se barre, et hop, comme par hasard, refra.fr redescend en bas de la file prioritaire des ressources, et hop, ça rame à nouveau
...
et donc le compte à rebours continue pour ovh avant le grand départ
ce qui m'ennuie le plus c'est que le mois de mars va être bien pourri niveau fréquentation, et la radio à droite elle tourne pas comme prévu ;
L'Administrateur