Problème connexion au site ou de chargement des CSS, images, js

Saxgard 2017-11-14 08:17:39 UTC #67

@ChristianD7 tu es aussi sur le cluster002?

J’ai fait aussi Un test ce matin vers les 8h50:

On voit ici que mon fichier css a mis 6s à se charger

A 9h07 :

Et sur pagespeed délai avant expiration refusé

Et un petit test via gtmetrix !
A 9h10 :

A 9h32 j’essaye de surfer sur mon site, ca patine et je tombe sur un err_connection_timed_out

A 9h48 un 502 bad gateway :

@vcasse vous etes toujours sur le coup? Constatez vous au moins toujours ce dysfonctionnement sur le cluster002? Ca fait presque un mois que le probleme est là.
Si c’est bien le cluster002 est il possible de déplacer mon site sur un autre cluster ?

Saxgard 2017-11-14 10:05:02 UTC #68

Euh je vois que le travaux est clos : http://travaux.ovh.net/?do=details&id=28227&PHPSESSID=6e7605007a6c3b0a9c36d0b53128cabe

@vcasse que dois je faire pour que les accès a mon site reviennent a la normal ? Ce matin c’était (c'est) encore chaotique avec des temps de chargements des éléments statiques qui mettent des plombes ou des err connections timed out. Il y a des moments d’accalmies de quelques minutes. Là je perd patience :/

ChristianD7 2017-11-14 10:15:01 UTC #69

@Saxgard : non cluster 17 filer 444. ça fait 1 mois que ça dure. Fonctionnement parfois excellent, d'autres fois blocages divers. J'attends. :-)
En ce moment c'est OK. J'ai un autre site : ecriptoire.org
Serveurs web : cluster006
Serveurs de données : filerz526
Aucun pbs. A tjrs bien fonctionné.
Ceci étant, pour avoir bossé 40 ans dans l'informatique, je sais qu'il est très difficile de mettre le doigt sur une ou des pannes intermittentes. Donc, pour moi, wait and see. Heureusement, ce ne sont pas des sites de commerce en ligne.

Saxgard 2017-11-14 10:41:06 UTC #70

J'ai conscience que ce genre de dysfonctionnement est difficile a détecter, mais lorsque qu'on fourni des tonnes d’éléments avec heures précises j'ai du mal à comprendre qu'ils ne voient rien. Comment leurs systemes de monitoring peuvent laisser passer ça ?
Quand je vois en plus que les travaux sont clôturés et qu'on reste sans réponse c’est difficile de rester zen :/

Saxgard 2017-11-14 11:36:04 UTC #71

Et ca continu encore, depuis ce matin c’est vraiment catastrophique.
Vers 12h20 je fais d'autres tests (je vide la cache de mon navigateur) et ça fait plus de 20 minutes que l'accès a mon site met des dizaines de secondes, voir plusieurs minutes (oui oui, ça patine, j'ai une page blanche et après plusieurs minutes il se charge)

Et toujours de quoi prouver ces dysfonctionnements :

https://gtmetrix.com/?job_error=P4ysXQ4k

Saxgard 2017-11-14 14:36:32 UTC #72

@vcasse : voici encore 2-3 exemples avec des cas de 502 bad gateway qui pourraient être utiles

A 12h20, après 45s un 502 bad gateway via Pingdom :

A 14h20 via gtmetrics, 75s de temps de chargement au niveau de la 1ere ligne :

A 15h06 (des 502 bad gateway sur des images):

Sur ce dernier exemple on voit que les images mettent des dizaines de secondes à se charger et 2 d'entres elles retournent un 502 bad gateway. c'est évidemment pas des cas uniques dans la journée mais uniquement quelques uns que je choppe au moment ou je fais des tests.

je précise encore une fois que pagespeed insights détecte également le soucis et que je peux également le constater en surfant sur le site d'autant plus facilement lorsque je vide ma cache au moment de fortes instabilités.

Dans le google search console, google m'indique également des 502 bad gateway

Toujours aléatoire mais très très fréquent. Avec de fortes instabilités pouvant durer des heures.
Aujourd'hui c'est particulièrement instable, alors qu'hier ça m'a semblé plus calme sur le peu de tests que j'ai effectué.

Saxgard 2017-11-15 12:18:20 UTC #73

J'ai encore eu le support au téléphone ce matin a priori ça viendrait de surcharges des WEBM. OVH n'arrive toujours pas à identifier la cause de ces surcharges. Même si je comprend que ca doit etre très difficile à détecter ça me met dans une salle position. Je ne pourrais pas rester comme ça encore longtemps :/

YannC3 2017-11-15 20:58:32 UTC #74

ce qui est quand même étonnant c'est que les autres personnes dont moi qui sommes sur le même cluster n'avons pas ces problèmes.

Saxgard 2017-11-16 09:14:06 UTC #75

Selon les dire du support ca n’affecte pas tout le cluster. Mais peu de sites (c’est pas tres rassurant dans la mesure ou c’est donc pour ovh peut etre moins prioritaire). Ca aurait un rapport avec la repartition des ressources ou un truc du genre. Ce qui rend le probleme compliqué c’est que mon site n’a pas un tres gros traffic, en temps normal il se charge tres rapidement etc. Rien qui justifie une surcharge et OVH essaye donc d’identifier le probleme. L’aspect aléatoire complique les chose meme si parfois ca peut etre surchargé pendant des heures. Il y a d’autres moments ou ca charge normalment et tres rapidement. Et ca date a priori « que » depuis quelques semaines.
Seul @vcasse pourrait donner plus de précision. Pour le moment je ne sais guère plus.

YannC3 2017-11-16 15:49:57 UTC #76

pas de bol quoi, il en fallait un

vcasse 2017-11-17 13:00:23 UTC #77

Bonjour,

Il s'agissait effectivement d'uns surcharge aléatoire sur nos serveurs webs. Elle était causée par de multiples facteurs en même temps :
- Sous dimensionnement de l'infrastructure suite à des migrations vers du nouveau matériel,
- Comptes d"hébergements exploitant trop de ressources suite à des hacks majoritairement.

Nous avons bien entendu revu nos systèmes de monitoring pour détecter en avance de phase ces soucis avant qu'ils n'impactent vos sites web.

Nous avons agit progressivement sur ces deux points afin de faire redescendre ces instabilité en ajoutant des machines petit à petit et en analysant et détectant de nouveaux patterns de hacks sur nos hébergements. Depuis mercredi après midi, nous n'observons plus ces instabilités d'infrastructure.

@Saxgard, cela fait deux jours que je teste sitacados.com sur pingdom, je tombe en dessous de 600ms à chaque fois. Peux tu me confirmer que tu vois aussi ces résultats sans les perfs aléatoirement basses ?

Dans tous les cas, nous continuons à jeter un coup d'oeil sur ce cluster dans les jours qui viennent.

Nous sommes désolé de l'impact que cela a pu avoir sur vos sites webs.

Vincent

Saxgard 2017-11-17 13:21:54 UTC #78

Bonjour

Encore une fois merci beaucoup @vcasse pour se retour. Avant de donner une réponse définitive sur le retour à la normal je vais me laisser quelques jours, histoire de vérifier si il n'y a pas toujours des pics d'instabilité. J'attends également quelques jours afin de vérifier la courbe des temps de chargement du Google Search console (qui met du temps à se mettre à jour).

La seule chose que je peux dire pour le moment c'est que je n'ai pas constaté de gros pics d'instabilité hormis ce matin ou je suis tombé une fois sur un 33s vers 9h40, ce qui je dois avouer ne m'a pas rassuré (peut etre un autre pb sous-jacent non détecté). Mais je n'ai pas reproduit ensuite d'autres résultats de ce type. Partant toujours du principe que je ne tests pas toutes la journée en continu.

Je ferais donc quelques tests et ferais un meilleur retour en début (milieu) de semaine prochaine. On est jamais trop prudent ;)

PS : au téléphone le support me disait que vous aviez essayé de me changer de WEBM, et que le problème persistait. Si je comprend bien ce sous dimensionnement de l'infra et les hacks affectait plusieurs WEBM, et je n'ai donc vraiment pas eu de chance ?

A prendre avec des pincettes, mais vers 14h30 j'ai constaté un pb similaire avec un autre site, les images et le site ont mis beaucoup de temps à se charger. J'ai fait à ce moment la un test pingdom et je suis tombé sur ça :

site sur :

Cluster 005
filer 2007
Performance 1

Le problème s'est peut être propagé sur d'autres serveurs. Quoi qu'il en soit difficile d'analyser avec ce site vu que j'ai l'Option CDN (perf1 ) pouvant être fausser les tests.

Et j'ai aussi remarqué via le Google Seach console des petits pics de temps de chargement depuis le 11 novembre pour un autre site également avec CDN (perf 1). Rien de suffisamment significatif mais...

Je préfère le signaler même si je n'ai pas plus d’éléments à fournir pour le moment pour confirmer ou non qu'il y a également un soucis (le même?) sur d'autres serveurs.

MartinF 2017-11-17 15:19:55 UTC #79

Bonjour,

je viens de lire avec grand intérêt tout ce post, et je pense avoir un problème similaire sur mon site web (problèmes de chargement de fichiers css, js, images qui bloquent / délaient l'affichage de la page).
Mon site (www.alternaweb.org) est hébergé sur le cluster 020 (http://cluster020.hosting.ovh.net).

J'avais écrit un post (https://community.ovh.com/t/erreurs-504-intermittentes/5350) avant d'avoir lu celui-ci.

@vcasse: pourrait-il s'agir du même problème ?

Merci,
Thomas

vcasse 2017-11-17 15:44:52 UTC #80

Bonjour @MartinF,

Nos monitoring ne remontent pas du tout le soucis que nous avions identifié sur le cluster002. Il y a probablement trés peu de chances que ce soit lié.

Ce que j'observe, c'est que votre site met beaucoup de temps à se générer à chaque requêtes en consommant beaucoup de processeurs et en effectuant des connexions à d'autres serveurs qui ralentissent la génération de la page.

Il y a beaucoup d'appels à api.wordpress.org. Je vous conseille de cacher les résultats de cette API pour éviter d'effectuer deux fois le même appel et ainsi réduire le temps de chargement de vos pages.

Bonne fin de journée,
Vincent

DamienM1 2017-11-21 11:15:08 UTC #81

bonjour,

je suis ce fil depuis quelque jours car je rencontre le même type de problème.

je constate encore aujourd'hui les dysfonctionnements :
- temps d'accès très long, jusqu'à 16s pour une page de 750Ko !, ici http://distilled-art.com/
- problème réguliers d'accès la la base de donnée qui plante wp ici http://mouvementutopia.org/

aucun message sur ce fil depuis 4 jours, mais pas d'amélioration chez moi...
@Saxgard, c'est résolu pour toi ?
merci pour vos réponses !

ppast.dev 2017-11-21 11:40:32 UTC #82

Suivant ce fil, je vois ce message.

La page en question (distilled-art.com) ne pèse pas 750ko, mais plutôt 2.4Mo (vu avec outils de dev Chrome) ! Avec 84 ressources externes à charger (CSS / JS), c'est loin d'être optimisé...

Pareil en rentrant dans le site. Il me semble que dans ce cas précis, le problème est plus lié à la conception du site (avec jquery etc.) ; par ex. la page "livres et magazines" télécharge quelques dizaines d'images non optimisées (250/300ko) chacune (normalement, il faudrait une version miniature de qq dizaines de ko et une version pour zoom utilisateur).

DamienM1 2017-11-21 12:39:42 UTC #83

hello @ppast.dev,

merci pour ta réponse, et oui, en effet, je n'ai pas vraiment cherché à optimiser le site, parce que je crois comprendre que ce n'est pas là le principal problème - mais je veux bien un éclaircissement, voire un démenti si je me trompe.

sur le fichier ci-dessous (où j'ai pris l'indication de poids, celui annoncé par pingdom), on voit deux temps d'attente très longs avant que l'ensemble se charge - dans les faits, il me semble que le chargement 'concret' du site se fait après le 2ème temps, celui de plus de 10s (auquel cas la page met moins de 2s pour s'afficher, et vu le but du site ce n'est pas un problème, c'est juste un site plaquette pour présenter mon travail à des personnes qui me connaissent déjà...).

j'ai demandé à plusieurs techniciens ovh d'où peut venir ce délai, sans réponse convaincante, mais j'ai l'intuition (peut-être fausse) que c'est chez eux que ça plante, et pas la configuration de wp qui ne va pas.

sachant que je gère plusieurs autres sites, construits peu ou prou de la même manière, et que je n'y rencontre pas ce délai bizarre (et où ai des temps de chargement 'normaux').

peux-tu me dire déjà à quoi correspondent réellement les délais indiqués par pingdom ? et donc si la piste du serveur est bonne ?

merci

vcasse 2017-11-21 16:27:10 UTC #84

Bonjour @DamienM1,

Je confirme que le soucis observé n'a plus lieu selon notre monitoring.

J'ai regardé un peu votre site web. Je pense que votre base de données ne doit pas être optimisée. J'imagine que vous devez avoir quelques tables bien remplis et que votre code effectue des recherches dessus sans utiliser d'index (S'agissant de wordpress, il se peut que cela soit une extension qui se provoque ces soucis).

Si vous observez les statistiques au sein de votre espace client, vous pourrez constater des centaines de requêtes SQL par minutes alors que votre traffic est dans le même temps de 10 à 15 requêtes par minutes sur votre site.

Cela signifie que chaque chargement de page effectue plusieurs requêtes dans cette base de données.

Etant donné qu'il y a des soucis de construction de la base de données, la durée moyen d'une requête SQL sur votre base est de 2 secondes. Il en suffit donc d'une dizaine pour que votre site ne s'affiche qu'en 20 secondes.

Je vous invite à rechercher le code qui effectue ce nombre de requêtes. Il arrive souvent que des extensions de mauvaise qualité ne soient à l'origine de ce genre de soucis.

Bien cordialement,
Vincent

DamienM1 2017-11-22 12:47:52 UTC #85

bonjour @vcasse,

merci d'avoir pris le temps de regarder ça.

dans un premier temps j'ai tout mis à jour puis nettoyé les bases de données (de distilled-art.com), sans progrès - j'ai donc désactivé toutes les extensions pour ne les réactiver que une par une, avec speedtest à chaque fois.

pour découvrir celle qui faisait planter l'ensemble, pourtant une extension réclamée par le thème oshine, la BE Portfolio Post - je le précise pour le cas où ça puisse servir à quelqu'un.

et les temps de chargement sont bien redescendus à 1s ou 1,5s, ce qui est très normal.

donc encore merci, et désolé d'avoir accusé ovh sur ce coup-là...

damien

vcasse 2017-11-22 13:05:30 UTC #86

Pas de soucis @DamienM1, c'est toujours un peu difficile à diagnostiquer.

Heureux que le soucis soit résolu.

A bientôt,
Vincent

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVH Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres OVH Community.