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

En jetant un œil sur la courbe "temps de chargement d'une page" dans le Google Search Console, j'ai l'impression que le problème date depuis fin octobre (bien avant le gros soucis de surcharge des loads balencers) :

[url=https://www.hostingpics.net/viewer.php?id=943860tempschargementgoogle.jpg][img]https://img4.hostingpics.net/thumbs/mini_943860tempschargementgoogle.jpg[/img][/url]

le 26/10 : 1300ms en moyenne
le 27/10 : 1700ms
le 31/10 : 1000ms
le 01/11 : 2400ms
le 02/11 : 1913ms
le 03/11 : 1400ms
le 04/11 : 2400ms

J'ai donc des temps de chargement moyens de 2s au lieu de 250ms habituellement. Très mauvais pour mon référencement ! Des temps de chargement observables particulièrement par les bots vu qu'ils ne font pas appel à la cache du navigateur et que le problème est à priori associé au chargement des fichiers statiques.

Vu que le problème est irrégulier, j'en déduis qu'à certains moment Google met beaucoup plus de 2s pour charger une page.

Pour moi le chargement est instantané.
Effectivement l'appel à Google peut être pénalisant, et je remarque que tous les liens aux images se fait par adresses absolues au lieu d'adresses relatives.

Que l'accès aux images se fasse par adresse absolue ou relative ne change rien au problème.

Comme indiqué le problème est irrégulier mais très fréquent.
En surfant sur mon site c'est très difficile à détecter car non seulement il faut tomber dessus quand ça arrive mais en plus la cache du navigateur vient ensuite fausser le test.

Une chose est sur, tous les bots rencontrent **très régulièrement** ce même soucis d'accès à mon site (ou du moins à ses éléments statiques) et les temps de chargement moyens des pages explosent.

J'ai essayé de faire "explorer comme google" dans le google search console et j'observe encore clairement que des fichiers n'ont pas pu être explorés par Google :

[URL=https://www.hostingpics.net/viewer.php?id=895494explorercommegoogle.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_895494explorercommegoogle.jpg[/IMG][/URL]

C'est grave pour mon référencement et j'en ai un peu marre de ces nombreux problèmes de serveurs depuis un an ou deux

Il y avait d'ailleurs déjà eu un problème similaire qui avait été résolu après des semaines à se battre pour qu'il soit identifié. Sachant qu'en plus plusieurs personnes étaient intervenues pour le signaler sur le forum !

Encore un petit test pingdom qui a merdé :

https://tools.pingdom.com/#!/et8jXH/http://www.sitacados.com

Il y avait d'ailleurs déjà eu un problème similaire qui avait été résolu après des semaines à se battre pour qu'il soit identifié

Il n'y a plus qu'à remettre les gants de boxe ! ;-)

J'aimerais déjà qu'un technicien d'OVH intervienne ici :/

J'ai horreur de ces problèmes qui sont généralement difficiles à détecter mais qui de notre côté pourrissent bien nos sites. C’est d'autant plus fatiguant quand il faut se battre pour montrer que le problème est bien là malgré les nombreux éléments de preuves fournies (même si je comprend que ce n'est pas toujours évident pour les techniciens) . J'espère que cette fois ci ça sera identifié et résolu plus vite.

Que l'accès aux images se fasse par adresse absolue ou relative ne change rien au problème.

Pas sûr!
L'accès par adresse relative permet d'afficher l'image directement SANS pas par l'extérieur du réseau.

Inutile de se focaliser sur les adresses absolues ou relatives. Le fait qu’elles soient en absolu ou en relative n’a jamais posé un probleme pour charger des images etc. A moins que le web a changé depuis fin octobre. :)

Le probleme vient clairement D’OVH. Precision je n’ai pas l’option CDN.

J’ai également précisé que parfois c’est la connexion au site qui ne se fait pas. Donc a priori le chargement du fichier html deconne aussi.
C’est totalement aléatoire. Ca peut toucher n’importe quels fichiers (voir mes essais pingdom)

Au fait, pourquoi ton site n'est pas en **_HTTPS_** ?

Avant de faire la migration en https je compte changer de framework et le format des url. De cette facon j’aurais besoin de faire qu’une seule redirection. En gros passer en https avec ce site est un peu plus compliqué. Par contre j’ai déjà passé mes autres sites en https. Pourquoi cette question ? Meme si le https est une consigne de GG ce n’est pas vraiment obligatoire. D’autant plus que je n’ai aucun espace membre dessus.

Je ne savais pas que le HTTPS était une consigne de GOOGLE. :)
Je crois plus à une recommendation du W3C.

Je me suis "baladé" sur ton site et je n'ai vu aucun problème apparent.

Inutile de se focaliser sur les adresses absolues ou relatives. Le fait qu’elles soient en absolu ou en relative n’a jamais posé un probleme pour charger des images etc. A moins que le web a changé depuis fin octobre. Donc inutile de focaliser la dessu :)

Le probleme vient clairement D’OVH.

Libre à toi de ne pas te focaliser sur les adresses absolues, cependant l'image que tu as publié ici montre qu'il y a quand même un soucis, ainsi que pour les accès Google.
Au demeurant que certains outils puissent t'alerter sur des dysfonctionnements rares et épisodiques cela ne représente que peu d'intérêt au regard de l'expérience utilisateur. Or nous sommes au moins deux à avoir pu consulter ton site sans aucune difficulté, et je ne vois pas pourquoi Octave ferait de l'ostracisme plus particulièrement sur ton hébergement.

Ca fait des années que j’utilise des adresses absolues (que ca soit bien ou non peu importe) je ne vois pas pourquoi depuis fin octobre elles poseraient ce type de soucis. Donc oui je peux affirmer que c’est une fausse piste :) Et je continu de ne pas voir le rapport entre les liens absolues et le probleme signalé, d’autant plus que c’est parfois directement la connexion au site qui pose probleme (l’accès a la page html). Exemple ici : https://tools.pingdom.com/#!/etLRTX/http://www.sitacados.com
En gros c’est le chargement de n’importe quel type de fichier qui semble poser soucis et de façon aléatoire.

Ce dysfonctionnement n’est pas si rare et anecdotique, suffit de voir les Temps de chargement moyens de mes pages sur l’image du google search console, et les differents resultats de tests pingdom, pagespeed etc que j’ai transmis. Si j’ai pu constater aussi facilement le probleme avec ces outils rien qu’aujurd’hui en quelques tests, c’est que ca reste suffisament frequent pour etre problématique. Le fait que vous n’ayez pas observé de probleme, ne signifie pas qu’il y en ai pas.

Sans chercher bien loin, du moment que je constate que du jour au lendemain google met plus de 2s en moyenne pour cahrger mes pages, il y a un probleme et OVH doit l’identifier et le résoudre.

L’aspect aleatoire rend evidemment difficile l’identification du probleme, mais seul OVH peut en connaitre l’origine dans le cas présent. (Probleme de charge?, de routage? Ou je ne sais quoi encore...).
Ce genre de problemes de chargements de fichiers ne peut venir que du coté des serveurs.

J’ai un site sur un 240 plan et 2 autres sur des perf1 qui ne semblent pas etre impactés, je soupconne donc un probleme ciblé sur ce cluster ou filer

Est ce que la migration vers apache 2.4 pourrait avoir un rapport ?
J’imagine qu’une directive incompatible avec la 2.4 dans mon .htaccess provoquerait une erreur 500?

Edit : j’ai vérifié et j’ai l’impression que le cluster 002 pour les 90plan a migré vers apache 2.4 en aout. Donc, ca ne semble pas lié.

Bonjour,

question bête : un ticket incident a-t-il été ouvert ?

Cordialement, janus57

Oui j’ai ouvert un ticket ;)

Bonjour,

je conseil de mettre le N° du ticket ici et de donner un max d'explications sur le ticket pour éviter qu'il sorte une réponse de leur FAQ de niveau 1 et escalade le ticket au niveau 2.

Car là sur le forum les techs OVH passant sur leurs temps libres, il y a plus de chance que la résolution se fasse via ticket voir téléphone que sur le forum, surtout si le problème est côté OVH et nécessite un tech niveau 2/3 avec les accès et/ou outils nécessaire pour chercher/trouver la root cause.

Car malheureusement d’après ce que j'ai compris/constaté c'est que les tech qui répondent en premier au ticket n'ont pas forcément tous les accès nécessaire pour faire des opérations avancés, donc parfois il faut être très lourdement insistant car ils ne font que suivre leurs procédures internes.

Si tu as twitter tu peu aussi essayé là bas avec ton N° de ticket.

Cordialement, janus57

Mon numéro de ticket : 8655680583

Sur le ticket je donne les mêmes infos qu'ici. Je ne vois pas ce que je peux dire de plus :/
Malheureusement je sais aussi que par ticket c’est souvent très compliqué et ça aboutit rarement à quelque chose surtout quand le problème est aléatoire et qu'ils n'arrivent pas à le détecter sur leur monitoring.

J'ai généralement plus de résultats via le forum, surtout quand certains finissent par se rendre compte qu'ils ont le même soucis et qu'ils viennent ajouter leurs preuves.

j'ai fait une autre vérification. J'ai un autre site sur le cluster 002 et à priori je n'ai aucun soucis. La seule différence c'est le filer et le fait qu'il soit sous perf1 avec CDN (le CDN fait tampon et élimine peut être une grande partie ces problèmes de chargement aléatoires)

La par exemple on voit qu'une image de 7 ko a mis plus d'1s à se charger :
https://tools.pingdom.com/#!/bIrvio/http://www.sitacados.com

En tout cas le problème persiste toujours aujourd'hui

Test pingdom vers 12h15. le chargement a mis plus de 5s au lieu de 700ms (en moyenne) sur ce serveur de test :
https://tools.pingdom.com/#!/evBBit/http://www.sitacados.com

vers 12h15 Pagespeed insight (temps de réponse du serveur 1s) :

[URL=https://www.hostingpics.net/viewer.php?id=362258pagespeedchargement3.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_362258pagespeedchargement3.jpg[/IMG][/URL]

Bon voilà de spreuves supplémentaires.

En surfant sur le site vers 12h30 il ramait sérieusement et a provoqué 2 erreurs.

La première "err_empty_response" :

[URL=https://www.hostingpics.net/viewer.php?id=956744erremptyresponse.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_956744erremptyresponse.jpg[/IMG][/URL]

La deuxième "502 bad gateway"

[URL=https://www.hostingpics.net/viewer.php?id=876814502badgateway.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_876814502badgateway.jpg[/IMG][/URL]

je vois vraiment pas ce qu'il faut de plus pour prouver que ça merde du côté d'OVH

Si un technicien pouvait passer par là??

Et ca continu encore et encore...

Tests vers 13h35-13h40 :

Pingdom :https://tools.pingdom.com/#!/eoRrks/http://www.sitacados.com

GTmetrix : https://gtmetrix.com/?job_error=0d1TPAhF

Pagespeed insight (6s de réponse serveur avec images qui ne se chargent pas)

[URL=https://www.hostingpics.net/viewer.php?id=793467pagespeedinsightchargement4.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_793467pagespeedinsightchargement4.jpg[/IMG][/URL]

vers 13h50 :

Gtmetrix : https://gtmetrix.com/reports/www.sitacados.com/n13rrrVi

J'ai appelé le support, mais évidemment (je m'y attendais) sur leur monitoring ils ne voient rien...

Est-ce qu'un technicien d'OVH pourrait passer par là SVP !

En jetant un œil sur la courbe "temps de chargement d'une page" dans le Google Search Console, j'ai l'impression que le problème date depuis fin octobre (bien avant le gros soucis de surcharge des loads balencers) :

J'ai la même courbe que toi avec des temps de chargement qui s'envolent depuis fin octobre dans Google Search Console, il y a un problème sur le mutu depuis fin octobre

cluster 002 / filer 33 / mysql55-154.business

@VincentB4 : Tu devrais également faire des tests de pingdom, gtmetrix, pagespeed insight pour voir si tu constate aussi des problèmes de chargement du site ou des éléments statiques de ton site. Et si c'ets le cas tu devrais les poster ici. En tout cas je vois que tu es sur le même cluster (002). Tu es sur quel offre? (90plan, pro, performance ?). Je ne sais pas si ton problème est lié au mien mais ça peut être une piste.

J'ai l'impression qu'entre 12h et 14h le problème est d'autant plus flagrant; en tout cas je constate que depuis le 12h environ une grande partie des tests que j'effectue aboutissent à de mauvais résultats.

En tout cas depuis les 12h environ quasiment un test sur 2 montre plusieurs secondes voir dizaines de secondes de chargement

Autres exemples :

https://gtmetrix.com/reports/www.sitacados.com/eSdHzeAn
https://tools.pingdom.com/#!/bXw6xJ/http://www.sitacados.com

Que faut-il faire pour se faire entendre ?

Bon a priori ce n'est pas un cas isolé

Tests effectués sur d'autres sites m'appartenant :

sitafamille.com (240plan cluster 003, filer 504) vers 15h40 :

https://tools.pingdom.com/#!/er4ClN/http://www.sitafamille.com

gameophage.com (perf1 avec CDN, cluster 002, filer 32) vers 15h50

https://tools.pingdom.com/#!/bRvbeN/https://www.gameophage.com

Bonjour, pour le site bustier-corset le problème vient surtout du fait qu'il est très très mal paramétré, d'ailleurs il ne l'est pas du tout, donc même avec de bonne conditions il ne sera jamais rapide alors avec des mauvaises pfff.

Mal paramétré ou non, passer de 5-6 secondes en moyenne sur gtmetrics a plus 50 secondes n'est pas justifié, ni les 502 bad gateway. Donc inutile ici de remettre en cause le site en question. Quoi qu'il en soit j'ai montré pleins d'autres exemples.
Ca ne fera pas réellement avancer le problème qui semble déjà suffisamment compliqué ;)

J'ai retiré ce qui concerne ce site (qui ne m'appartenait pas) pour éviter que certains partent sur de mauvaises pistes. J'ai de toute façon donné pleins d'autres exemples qui devraient largement suffire pour pointer du doigt le problème.

le problème est connu http://travaux.ovh.net/?do=details&id=27828
les derniers travaux devant être fait cette nuit il faut espérer que tout va bien se passer

J'espère que tu dis vrai mais j'ai un doute, car dans les travaux en question ils parle juste de moderniser leur infrastructure et ils ne parlent pas de dysfonctionnement en particulier.

J'ai l'impression en plus que ça s'est empiré.
Rien que ce matin a mon premier accès sur le site il a fallu plusieurs secondes pour qu'il s'affiche et j'ai eu droit quelques minutes après a un 502 bad gateway entre 11h et 11h25.

[URL=https://www.hostingpics.net/viewer.php?id=748280502badgatewaynginx.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_748280502badgatewaynginx.jpg[/IMG][/URL]

Toujours pas de réponse à mon ticket et toujours aucun technicien n'intervient ici !!

je confirme ça rame, ça rame, ça rame ...

et un beau 403 youpiiii
http://travaux.ovh.net/?do=details&id=28223
"We will increase capacity on our Load Balancers for all our clusters in GRA and P19."
ah oui tout de suite on la sent bien l'amélioration
Mais pourquoi autant de haine envers le P19

@VincentB4 et @YannC3 vous pouvez donner vos url ? ça aiderait peut être les techniciens qui passeraient "éventuellement" par là. Ou pouvez vous mes les envoyer en Mp pour que je puisse voir si on a affaire au même soucis.

Quoi qu'il en soit avec ces travaux en cours on ne sait toujours pas si ils sont identifié ce problème ou non et si c'est lié.

@Saxgard, je ne souhaite pas communiquer mes URL mais je pense que nous sommes confrontés à la même problématique. Images qui ne chargent pas, erreurs 502 / Bad gateway, lenteurs ponctuelles, temps de chargement qui s'envolent dans Google Search Console, erreurs d'exploration Googlebot, avalanche de notifications des outils de monitoring, baisse du chiffre d'affaires, mise en danger du SEO, perte de confiance dans l'infrastructure OVH.

@VincentB4 as tu ouvert un ticket ? Plus il y aura de ticket signalant le même problème et plus ça aura de poids.

Bon après mon deuxième appel au support et les nombreux éléments que je leur ai fourni via le ticket il semblerait qu'ils aient enfin identifié le problème. Et ça vient bien de chez eux. Les administrateurs sont donc dessus et d'après la personne que j'ai eu au téléphone ça devrait être résolu d'ici 1h max.

Je croise les doigts

Bonjour @Saxgard,

Effectivement, nous avons identifié des instabilités sur le cluster002 depuis le 27 octobre. Nous sommes actuellement en train de restabiliser le clusters en ajoutant quelques serveurs manquants.

Nous allons aussi investiguer pour comprendre pourquoi nos systèmes de monitoring n'ont pas été suffisant pour agir proactivement.

Merci pour ces remontées détaillées
Vincent

@vcasse : Merci beaucoup pour ce retour, rassuré de voir que le problème a enfin été identifié
Pourrez vous nous avertir lorsque se sera stabilisé vu qu'il n'y a pas de travaux en cours ?

en tout cas a 16h36 le problème n'est toujours pas résolu :(

Cela devrait commencer à aller mieux, les premiers serveurs sont fonctionnels.

Nous allons continuer à en déployer d'autres afin que les instabilités disparaissent.
http://travaux.ovh.net/?do=details&id=28227

Je viens de tester ton site avec pingdom plusieurs fois de suites, tu es de nouveau en dessous de 700ms. Peux tu me confirmer que tu observes la même chose ?

Vincent

merci pour les infos et le suivi @vcasse

@vcasse : ok merci, je ferais quelques tests un peu espacé et ferais donc un retour ce soir et un demain en début d'après midi. Je ne voudrais pas tirer de conclusion hâtive car j'ai déjà eu l'impression qu'à certains moments de la journée ça pouvait être plus fluide qu'à d'autres. ;)

J'ai déjà fait 4 ou 5 tests qui étaient constant (autour de 600-700ms) et je suis tombé a nouveau sur un mauvais tests (2,8s) vers 17h12 :

https://tools.pingdom.com/#!/cPnJQw/http://www.sitacados.com

et un autre de plus de 3s ver 17h15 :

https://tools.pingdom.com/#!/dPi0zW/http://www.sitacados.com

Bon je continu de tester dans la soirée et demain et je vous tiens au courant. Pour l'instant ce n'est malheureusement pas très concluant :/

Bon bin test suivant plus de 5s :

https://tools.pingdom.com/#!/exjOgA/http://www.sitacados.com

plus de 15s

https://tools.pingdom.com/#!/YzSdC/http://www.sitacados.com

Effectivement, la stabilisation est encore en cours :)

Je vais attendre ce soir et demain pour faire d'autres tests alors. ;)

Bon après être resté plus de 3h sans effectuer de test, j'ai voulu refaire 2-3 tests vers 21h et il y a toujours des instabilités.

Exemple ici avec presque 4s de chargement au lieu des 600ms-700ms en temps normal :

https://tools.pingdom.com/#!/d2w4du/http://www.sitacados.com

On voit que l'image bas_menu_m.jpg a mis 3,5s pour se charger

Test a 21h03 on est a 9s (plus de 8s rien que pour charger la page html) :

https://tools.pingdom.com/#!/esPSPe/http://www.sitacados.com

J'ai l'impression que le problème n'a pas été intégralement identifié :/

Bonjour,

je rappel que la tâche n'est pas close (Cf : http://travaux.ovh.net/?do=details&id=28227)

Cordialement, janus57

@vcasse a demandé de vérifier et c’est ce que je fais :) Et pour l'instant le problème est toujours là (difficile encore de juger si c'est plus stable ou non de part son côté aléatoire). La tâche n'est pas close car ils ont aussi besoin de retour.
Je pense qu'ils peuvent aussi avoir encore besoin qu'on leur fournisse des heures où des dysfonctionnement sont constatés, et plus ils auront de retour à ce niveau et mieux ça sera.

On dirait que ca marche par vague. Je vais des fois faire plusieurs bons tests d'affilé, ou alors à l'inverse enchaîner plusieurs mauvais tests. Mais ça reste difficile à confirmer

Je verrais donc demain entre 11h et 15h, il m'a semblé que vers ces heures c'était particulièrement instables (peut être qu'une impression).

Quoi qu'il en soit à 21h13 j'ai aussi voulu accéder à cette page : http://www.sitacados.com/sites-jeux-gratuits-simulation-vie.html et elle s'est affiché au bout 20s minimum.

P19 cluster02 "Ce site est inaccessible"
et cela continu encore et encore
http://travaux.ovh.net/?do=details&id=28238
"We encounter issues on our front-end load-balancer since 2017-11-09 06h22 UTC."
euh je dirais plutôt depuis le 2017-11-03

Idem : site inaccessible "ERR_CONNECTION_TIMED_OUT" constaté depuis 8h15 (mais ça dure peut être depuis bien plus longtemps)
Et c’est la même chose pour de nombreux autres sites hébergés chez OVH et qui ne sont pas forcément sur le cluster 002 .
Le site d'OVH et la page travaux merde également.
J'ai également eu sur le site d'OVH un ERR_EMPTY_RESPONSE, une erreur que j'ai obtenu sur sitacados il y a 2j (voir plus haut)
S'agit il d'un problème différent qui s'ajoute au notre ou tout est lié?

Ca pourrait rejoindre ce que je pensais plus haut (et dans mon ticket en cours), que le problème que je signale depuis le début n'affecte peut être pas forcément que le cluster 002 et encore moins uniquement les 90plan comme stipulé dans le travaux en cours.

Par contre j'ai 2 autres sites sur performances 1 qui sont accessibles dont 1 qui est pourtant sur le cluster 002. Peut Etre grâce au CDN.

P19 out depuis 7h ce matin SBG out depuis 1 h à peut près, les pannes s'enchainent depuis une semaine

Sur la page https://www.ovh.com/fr/support/status/

J'ai pu lire ceci :

> OverTheBox :: Hosts OverTheBox à SBG (il y a une heure)
> Task Type: Incident
> Category: Backend / Core
> Status: In progress

> Nous rencontrons actuellement des perturbations sur le datacentre de Strasbourg, lié à https://travaux.ovh.net/?do=details&id=28244
> En savoir plus
> Datacenters :: SBG1 (il y a une heure)
> Task Type: Incident
> Category: Strasbourg 1
> Status: In progress

> Détails : Nous avons un dysfonctionnement électrique dans le datacentre, nous investiguons.

> Details : We have an electrical dysfunction on the datacenter. We investigate.

> Comments:
> Date: Thu, 09 Nov 2017 07:55:58 +0100
> Nous avons un problème d'alimentation électrique, apparemment les groupes électrogènes n'ont pas fonctionné correctement. Dans SBG1 se situe la salle de routage du site. Les routeurs sont down depuis 7h14.
> En savoir plus

Je n'arrive pas à en lire plus mais a priori ça semble être un problème différent qui vient juste s'ajouter au notre (et ça commence à faire beaucoup). Sauf si le problème signalé était annonciateur de ce qui est en train de se passer.

Je suis sur le cluster 17 et ça fait un mois qu’il y a des pbs de ce type et qu’OVH me balade sur des pannes intermittentes. Pages blanches, le serveur ne répond pas, temps de réponde allant jusqu’à 30 secondes sur l’accueil site (normalement, moins d’une seconde pop-up inclus, sans lui 1/2 seconde). Cerise sur le gâteau, aujourd’hui c’est l’accès à l’espace client. Le premier niveau est dépassé, et fait ce qu’il peut en racontant des conneries, de préférence en mettant en cause le site client. Moi, OVH j’en ai assez. Ils ont grossi trop vite et ne maîtrisent plus leur infrastructure. On empile, on met des robots, des frontaux et autres switchs, de la virtualisation à outrance, on bourre les serveurs et les filers, etc., et ça foire.

plus de mail c'est la fête
http://travaux.ovh.net/?do=details&id=28250
très pratique pour un site de vente

Deux de mes sites sur mutualisés (performance 1) sont HS : err_timed_out, ERR_CONNECTION_RESET, ERR_CONNECTION_TIMED_OUT et j'en passe :

https://www.gameophage.com
Cluster 002
filer 32
Performance 1

https://www.noubliepasdecrire.com
Cluster 005
filer 2007
Performance 1

Je n'arrive pas non plus à accéder à l'espace client

et Sitacados montre toujours des instabilités

C'est le gros bordel et ca fait plusieurs jours que ça dure. Les pb de ce matins n'arrangent clairement pas les choses.

@vcasse des infos ?
Normalement RBX et les mutualisés devraient être opérationnels ?

@vcasse : Ben non, mais alors pas du tout. Bloqué.

Bonjour,

Les pannes de ce matin ont été causées par un soucis réseau majeur.
Toutes les informations se trouvent dans la tâche travaux.

http://travaux.ovh.net/?do=details&id=28244

En paralléle, @Saxgard, nous continuons la diminution des instabilités sur le cluster002.

Vincent

Bonjour @vcasse

Merci pour ce retour ;)

Si ca peut aider pour la stabilité du cluster 002 j'ai eu deux beaux 502 bad gateway à 15h20 et a 15h30 sur un autre de mes sites : gameophage.com.

https://www.gameophage.com
Cluster 002
filer 32
Performance 1

Gameophage n’est pas sur un 90plan, je le précise car sur le travaux suivant vous indiquez seulement cluster 002 (90plan) : http://travaux.ovh.net/?do=details&id=28227

A 15h36, 15h41, 15h43 , sitacados a mis plus de 10-20s pour s'afficher (je prenais soins de vider la cache pour le constater).

Et un petit pingdom pour la route :

https://tools.pingdom.com/#!/eleonj/http://www.sitacados.com

sur pagespeed insights j'ai de beaux "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. Vous pouvez actualiser la page pour réessayer."

Les améliorations (si il y a ) au niveau de la stabilité ne sont pas très concluantes. L'impression qu'il y a des vagues d'instabilités semble de plus en plus fondée (peut être liés à des charges élevées à des instants T mais fréquents). On tout cas depuis presque une heure c'est chaotique.

C'est quoi ce bordel !

https://tools.pingdom.com/#!/dZdZ3E/http://www.sitacados.com

Ca a mis 60s (durée max de pingdom), mais en plus c'est meme pas le screen de de mon site qui s'affiche (ca me la fait qu'une fois), pourtant c'est bien mes éléments statiques qui se chargent sur le waterfall

Autre pingdom a 60s :

https://tools.pingdom.com/#!/cFuaDR/http://www.sitacados.com

POur résumer, c'est pareil qu'hier. Le cluster 002 n'est clairement pas en train de se stabiliser. Depuis 1h30 c’est tout simplement catastrophique. Il y a donc toujours des longs moments dans la journée où c'ets chaotique avec pas mal d'instabilité tout au ong de la journée.

Ça devient difficile de garder son calme :/
Ca fait des jours et des jours que ça dure et pendant ce temps mon référencement risque fortement d'en pâtir.

@vcasse j'ai bien l'impression que vous n'êtes pas sur la bonne piste ou alors ca prend vraiment beaucoup de temps pour que cette stabilité soit observable

@vcasse vous pourriez aussi vous attaquer aux pbs d'instabilité du cluster 17 dans la foulée. cf. la nuit dernière vers 1 h 20 / 1 h 28 (peuvent pas dormir la nuit les clients ! :-) :-(
Parce que l'instabilité semble être un mode de fonctionnement qu'affectionne particulièrement ce cluster. Un bipolaire, probablement.

Nous n'observons pas d'instabilité sur le cluster017. Pouvez vous me fournir un compte que je puisse regarder plus précisément ?

Cordialement,
Vincent

J'ai l'impression que pingdom ne fonctionne pas trés bien ce soir. Il me retourne des erreurs 500 sur son propre site.

Enfin, plus précisément, les tests depuis San José ne fonctionnent pas trés bien. Depuis la Suède, il n'y a aucun soucis et je n'obtiens pas les mêmes soucis.

Avez vous fait les tests depuis un autre prestataire ?

Je viens de tester quelques fois que GTmetrics et j'obtiens de bon résultats (~1s depuis le Canada)

Vincent

@vcasse : Vous intervenez sur le forum juste au moment où il y a une accalmie :(
Entre 15h et 17h (17h30) vous auriez eu de tout autres résultats et quasiment systématiquement

oui j'ai constaté ces instabilité avec pagespeed insight également (je le dit d'ailleurs un peu plus haut) et en surfant tout simplement (en prenant soin de vider la cache). J'ai fourni quelques heures où ça a mis plusieurs secondes voir dizaines de secondes à s'afficher sur mon navigateur.
Normalement j'ai fourni mon adresse ip public par téléphone au support pour que vous puissiez faire les vérifications.
Je n'ai plus re-testé avec gtmetrics parce que pingdom permet de tester à partir de Stockholm (donc plus proche). De plus j'avais les mêmes mauvais résultats avec pagespeed insights et en surfant sur le site.

J'ai évidemment arrêté de faire des tonnes de captures d'écrans parce qu'à ce stade ça me semble inutile.
Faut vraiment faire quelque chose, des années de boulot en matière de référencement risquent de partir en fumée. Et je parle même pas de la perte de visiteurs.

Je voudrais pas que ça fasse comme en aout-septembre 2016 où un problème assez proche avait été signalé et il a fallu plusieurs semaines pour qu'il soit enfin identifié. Vous aviez fait d'ailleurs un beau compte rendu du problème et des solutions apportées qui pourrait peut être vous donner des pistes .

Voici le topic en question :
https://forum.ovh.com/showthread.php/111373-Pb-chargement-CSS-JS-images-al%C3%A9atoire-ou-Site-Web-Inaccessible-1-sec

@vcasse : Bien sûr, puisque c’est aléatoire, sans compter que l’incident de ce matin a probablement contribué. Mais cette nuit, je peux vous assurer qu’entre 1 h 20 et au moins 1 h 28 il était impossible d’accéder au site. Cela dure depuis environ 1 mois. Ça va ça vient (utlbergerac.com). Cet après-midi aussi aux environs de 14/15 h (message de ma présidente : connexion impossible !). Un jour on m’assure qu’on a fait le nécessaire, le surlendemain ça foire. Moi, je ne constate aucune anomalie dans les logs. Un jour on me parle de connexions sortantes (rien de bloquant), un autre de l’index.php, de conflit de code au niveau php (comme si le même code pouvait se comporter différemment de temps en temps ??), un autre on me dit qu’il n’y a aucun pb avec le filer 444 ou le cluster 17, etc. Moi, je dis que quand un serveur ne répond pas pour une requête qui fonctionne correctement la plupart du temps, il ne faut pas accuser le code. Ou alors, 40 ans d’informatique ne m’ont rien appris (je ne suis pas un pro du WEB, mais je sais ce qu’est une architecture informatique pour en avoir construit).
Ceci étant, je sais par expérience qu'il est extrêmement difficile de trouver l'origine d'une "panne" intermittente (surtout avec les empilement technologiques actuels). Désolé de ne pouvoir vous aider plus. Mais si çà

Histoire de montrer d’autres preuves a nouveau , autres que pingdom, voici un résultat de Gtmetrix a 19h14

https://gtmetrix.com/reports/www.sitacados.com/FV7IxEtZ

quasiment au même moment sur pingdom :

https://tools.pingdom.com/#!/jxrl0/http://www.sitacados.com

Il y a donc eu une une forte instabilité entre 15h et 17h30 puis une accalmie entre 17h30 et 19h environ et à nouveau des signes d’instabilité constatés après 19h. et ensuite j'en ai eu marre de faire des tests!

J'ai voulu profité du fait que ça semblait à nouveau instable vers 19h pour le prouver avec un autre outil que Pingdom

J'ai l'impression qu'il vous manque un regard sur une couche de votre infrastructure au niveau de vos systemes de monitoring. :/

@vcasse
https://tools.pingdom.com/#!/2f2LQ/utlbergerac.com
https://gtmetrix.com/reports/utlbergerac.com/fLsKIpje

@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
https://tools.pingdom.com/#!/dTETXM/http://www.sitacados.com
https://tools.pingdom.com/#!/W7LQ5/http://www.sitacados.com

Vers 10h22
https://gtmetrix.com/reports/www.sitacados.com/ZFHnOLp1

Vers 10h24
https://tools.pingdom.com/#!/dZ5LgK/http://www.sitacados.com

Vers 10h30
https://tools.pingdom.com/#!/d32rgh/http://www.sitacados.com

et voici quelques captures de pagespeed insights :

vers 10h05

[URL=https://www.hostingpics.net/viewer.php?id=572904ovh10h05.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_572904ovh10h05.jpg[/IMG][/URL]

vers 10h12

[URL=https://www.hostingpics.net/viewer.php?id=550924delaiexpireovh.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_550924delaiexpireovh.jpg[/IMG][/URL]

vers 10h26

[URL=https://www.hostingpics.net/viewer.php?id=368894ovh10h26.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_368894ovh10h26.jpg[/IMG][/URL]

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

https://tools.pingdom.com/#!/oyvCL/http://www.sitacados.com
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 :

https://tools.pingdom.com/#!/cHYuv4/http://www.sitacados.com

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.

[URL=https://www.hostingpics.net/viewer.php?id=396211pagespeedinsightssam16h57.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_396211pagespeedinsightssam16h57.jpg[/IMG][/URL]

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.

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

@ChristianD7 tu es aussi sur le cluster002?

J’ai fait aussi Un test ce matin vers les 8h50:
https://tools.pingdom.com/#!/efat3d/http://www.sitacados.com
On voit ici que mon fichier css a mis 6s à se charger

A 9h07 :
https://tools.pingdom.com/#!/cw5Dds/http://www.sitacados.com
Et sur pagespeed délai avant expiration refusé

Et un petit test via gtmetrix !
A 9h10 :
https://gtmetrix.com/reports/www.sitacados.com/TcKoKCw7

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

[URL=https://www.hostingpics.net/viewer.php?id=656460errconnection14119h32.jpg][IMG]https://img4.hostingpics.net/thumbs/mini_656460errconnection14119h32.jpg[/IMG][/URL]

A 9h48 un 502 bad gateway :
https://tools.pingdom.com/#!/dvMNz9/http://www.sitacados.com

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

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

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

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

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
https://tools.pingdom.com/#!/eP77S0/http://www.sitacados.com

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

https://tools.pingdom.com/#!/cHWjh3/http://www.sitacados.com

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

https://gtmetrix.com/reports/www.sitacados.com/TFhExtK3

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

https://gtmetrix.com/reports/www.sitacados.com/7NA3oxXH

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

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

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.

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.

pas de bol quoi, il en fallait un

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

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.

https://gtmetrix.com/reports/www.sitacados.com/bP8xCiIG

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 :

https://tools.pingdom.com/#!/ej3NW3/https://www.noubliepasdecrire.com

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.

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.ovhcloud.com/community/fr/erreurs-504-intermittentes?id=community_question&sys_id=298ee944fd1e8e902d4c483e6acd5181) avant d'avoir lu celui-ci.

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

Merci,
Thomas

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

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/http://1art.com/art.com/
- problème réguliers d'accès la la base de donnée qui plante wp ici http://mouvementutopia.org/ 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 !

Suivant ce fil, je vois ce message.

La page en question (1art.comart.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).

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

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

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 http://www.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

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

Heureux que le soucis soit résolu.

A bientôt,
Vincent

Bonjour @vcasse

Bon a priori en effet ça va beaucoup mieux avec sitacados, je n'ai pas observé depuis de grosses instabilités hormis quelques petits pics de temps de chargement mais très ponctuels pouvant être associé j'imagine à une petite surcharge des serveurs acceptable sur du mutualisé. Et sur le Google Search console le temps de chargement des pages est redescendu en dessous des 220ms.
Je reste quand même a l’affût et ne manquerait pas de signaler si je constate a nouveau un gros pics d'instabilité.

Je souhaite cependant signaler ceci :

Aujourd'hui je viens de tomber sur un 502 Bad gateway vers 13h57 avec mon site gameophage.com également hébergé sur le cluster 02 :

filer : 32
cluster : 002
performance 1

Ce n’est pas la 1ere fois que je tombe sur des 502 depuis fin octobre avec gameophage. Mais ca reste aussi très ponctuel. Le site n'a jamais souffert de gros pics de temps de chargement comme pour sitacados.

J'ai également choppé le 21/11 sur sitacados un err_connection_reset détecté par Gtmetrix :

le 21/11/17 https://gtmetrix.com/?job_error=ePqCCbUp (Je n'ai pas vérifié l'heure désolé mais il me semble que c'était vers 17h)

Salut, j'ai le même soucis sur le même cluster 002 en performance 1. J'ai acces au site mais plus au panel admin, j'ai 502 ou 504 bad gateway. Je suis au tel avec ovh actuellement

Tu pourras nous faire un retour stp

Problème trouvé. Je suppose que vous avez un prestashop en 16.0.4 ou 1.6.0.5.

Renommez le module "gamification" en "gamificationOLD" et ça va revenir.

Astuce trouvée sur le site de webbax et c'est la hotline dysfonctionnement de OVH qui m'a indiqué ou chercher, à savoir que site envoyait des requêtes vers le site gamification prestashop.

je suis encore tombé sur un 502 Bad gateway vers 18h22 sur mon site gameophage.com qui est également sur le cluster 002.
Pour le peu que je surf dessus chaque jour ces erreurs 502 m'ont l'air un peu trop fréquentes.

gameophage.com
filer : 32
cluster : 002
performance 1

@vcasse si tu pouvais voir ce qu'il en est :/ j'ai indiqué un autre 502 bad gateway il y a 2 jours (si ça peut aider, voir plus haut)
A chaque fois quand ca arrive c'est ponctuel et instantané et je ne constate aucun temps de chargement élevé. Difficile de faire la comparaison avec sitacados étant donné que sur l'autre site j'ai option CDN.

PS : pour sitacados.com je ne détecte plus de temps de chargement élevés sur de longues périodes et je n'ai pas eu d'erreurs 502

Bonjour,
Je me permets de participer à ce fil car je rencontre un problème similaire sur les deux sites https://flockyou.fr et http://1promo.frpromo.fr où les Google Bots ne prennent pas en compte le CSS et le JS et où certaines ressources semblent charger aléatoirement. Les deux sites sont sur le même hébergement et sur deux CMS différents (Prestashop et Wordpress). L'aperçu de la page donné par la Search Console fait peur à voir, et comme l'indique Saxgard, cela pénalise sûrement le SEO de ces deux sites.
@vcasse , serait-il possible de regarder ce qu'il en est pour que je puisse relancer les tests avec la Search Console et vous confirmer que toutes les ressources sont bien prises en compte svp? Le problème semble présent surtout sur les pages produits et catégories où les fichiers css et js ne sont jamais pris en compte par les Google Bots ("Autre erreur").

Merci d'avance.