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

ChristianD7 2017-11-11 02:31:07 UTC #64

@vcasse

Saxgard 2017-11-11 09:58:42 UTC #65

@vcasse :

Vendredi je n'étais pas chez moi et je n'ai donc pas pu faire de reels tests

Par contre samedi 11, dès mes premiers tests entre 10h et 10h30 je suis d'entrée tombé sur un pic d'instabilité :

Vers 10h05
https://gtmetrix.com/?job_error=BtpYcrRi

Vers 10h20

Vers 10h22

Vers 10h24

Vers 10h30

et voici quelques captures de pagespeed insights :

vers 10h05

vers 10h12

vers 10h26

je n'ai évidemment pas eu besoin de faire 100 tests pour tomber sur ces résultats, je ne sais pas si le pic d'instabilité a commencé avant 10h et si il a durée après 10h30.
Et entre chacun de mes tests il doit forcément y avoir d'autres pics

Evidemment sur le support (ticket 8655680583) on me dit que c’est lié à la grosse panne de jeudi alors que mon problème date de bien avant. Comment tout mettre dans le même panier. Via les tickets c'est très difficile de se faire entendre :/

J'espère donc obtenir de meilleurs résultats via le forum et je compte beaucoup sur vous @vcasse, l'année dernière vous aviez fini par trouver un probleme assez proche et complexe. A priori il y avait plusieurs patchs nécessaires à plusieurs niveaux :

rappel de vos solutions en 2016 (https://forum.ovh.com/showthread.php/111373-Pb-chargement-CSS-JS-images-al%C3%A9atoire-ou-Site-Web-Inaccessible-1-sec) :

D'ailleurs, je vous avais promis un résumé des patchs effectués. En réalité, le problème est complexe car nous avons plusieurs causes qui peuvent provoquer les connexions reset. A chaque fois que nous avons appliqué des patchs, nous avons réduit les connexions reset. Cependant, nous les avons jamais fait disparaitre totalement.

Nous nous sommes d'abord rendu compte de connexions qui étaient closes par nos serveurs web lorsque les load balancers tentaient de se connecter dessus. Il étaient du à une différence de durée de vie des connexions TCP. En gros, les loads balancers, lors de fortes charges, tentaient d'ouvrir des connexions déjà établis, ce que les serveurs web refusaient : connexion reset. Ce patch a été appliqué durant l'été.

Nos load balancers appliquent souvent des changements de configurations pour appliquer les nouveaux certificats SSL (nous en avons plusieurs milliers par jour). Lors de ces changements de configurations, nous avons identifié un bug qui entrainait la réutilisation des connexions TCP déjà ouvertes. Ce bug a été corrigé par un patch aux alentours du 14 septembre. Nous n'avons plus observé ce bug ensuite.

Nous avons découvert un bug dans notre anti-ddos qui bloquait, de manière aléatoire, quelques premières connexions. Ce blocage coupait la connexion TCP : connexion reset. Ce patch a été déployé aux alentours du 16 septembre. Depuis, les connexions reset lors de la toute première connexion n'ont plus lieu.

Nous avons aussi testé plusieurs autre patchs qui ne se sont pas révélés fonctionnels avant, et depuis ces autres patchs.

Depuis quelques jours, nous explorons une nouvelle piste. Depuis le début de l'après midi, nous avons appliqué un patch sur http://www.sitacados.com/
N'hésitez pas à nous indiquer si vous reproduisez les connexions reset dessus cet après midi.

Si ça peut vous aider

Je ne vais pas passer tout mon week end à faire des tests et je ne pourrais donc pas indiquer tous les pics du week end. Mais je pense que vous avez suffisamment d'éléments.

edit : j'ai refait 3-4 tests vers 12h et il y avait des pics d'instabilité :

ou des "délai d'attente dépassé sur pagespeed"

Et dans le google search console les temps de chargement d'une page explosent !

@vcasse dites moi que vous êtes toujours sur le coup SVP , et que vous constatez bien ses dysfonctionnements de votre côté.

edit : il est 14h18 j'ai voulu refaire quelques essais et c'était encore tres instable!

encore un exemple parmi des centaines d'autres :

Ou des secondes de chargements constatés sur pageSpeed insights voir des "Délai avant expiration dépassé lors de l'exploration de la ressource principale. Assurez-vous que la page s'affiche dans un navigateur et réessayez. "

edit : vers 16h57, je passe encore 5 minutes juste pour tester et je vois que c’est encore et toujours assez chaotique.

et toujours pareil, et il me suffit de vider la cache de mon navigateur pour me rendre lors des gros pics de dysfonctionnement, que la page mais effectivement beaucoup de temps à se charger.

ChristianD7 2017-11-14 06:43:12 UTC #66

Ce matin : http://www.webpagetest.org/result/171114_KV_a59be26892406ac9b4f1b1980605fe3a/

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

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.