OVH Community, votre nouvel espace communautaire.

Pb chargement CSS, JS, images aléatoire ou Site Web Inaccessible 1 sec


romainovh
04/10/2016, 22h20
Sinon c’est dommage que tu ne sois pas intervenu lorsqu'on avait justement besoin de personnes pour signaler les mêmes problèmes et donner des infos supplémentaires qui pouvaient aider le support.
- Je n'ai pas remarqué (ou très peu) de souci sur des sites web ovh, et les éventuelles infos que j'aurai pu fournir étaient déjà dans la discussion ;-)

- Ok pour les logs, qui sont gérés à part.

-
Pour le site du monde et twitter ça peut venir de pleins d'autres choses. tout n’est pas forcément a mettre dans le même panier.
On est d'accord, j'ai bien mis un bon smiley à la fin de ma phrase.


Merci pour vos réponses.

Daniel60
04/10/2016, 19h22
Voici ce que j'ai déjà posté concernant les logs le 22 septembre sur le fil mail :
Acccès aux logs
Bonjour,

Depuis plusieurs semaines l'accès aux logs web devient problématique.
J'ai une tâche cron qui plante une fois sur trois lors de la récupération des fichiers.
En accès web ce n'est pas toujours fameux : Firefox m'annonce parfois que la connexion n'est pas sécurisée et j'ai même obtenu ceci "Une erreur est survenue pendant une connexion à logs.ovh.net. SSL a reçu un enregistrement qui dépasse la longueur maximale autorisée. Code d’erreur : SSL_ERROR_RX_RECORD_TOO_LONG".

Votre avis ?

bd3699
Le problème est toujours là.
Erreurs du cron à 6h33 :
05/06/08/14/15/16/18/22/23/24 septembre
02/04 octobre et ça continue 05/09/11 octobre

vcasse
04/10/2016, 14h37
Citation Envoyé par romainovh
Bonjour,

J'ai suivi cette discussion sans intervenir, car je ne rencontrait pas beaucoup ce problème, hormis sur les logs.

Cependant, ce midi 04/10/2016 (entre 12h35 et 12h42), mon Firefox m'a refait "La connexion avec logs.ovh.net a été interrompue pendant le chargement de la page.".
Plusieurs fois...

J'ouvre une autre discussion avec un point que je n'espère pas lié aux derniers patchs.
https://forum.ovh.com/showthread.php...-les-login-mdp

J'ai de temps en temps l'erreur de chargement des js ou css sur d'autres sites comme Lemonde ou twitter... je ne pense pas qu'ils chez ovh
Bonjour,

En ce qui concerne logs.ovh.net, nous allons regarder.
Mais l'infrastructure n'est pas tout à fait la même, il est grandement possible que cela vienne d'ailleurs.

Cordialement,
Vincent

saxgard
04/10/2016, 14h34
Bonjour

@romainovh : Concernant logs.ovh.net il peut effectivement s'agir d'un autre problème. Un patch ne résout pas forcément tous les problèmes des hébergements d'OVH

Pour le site du monde et twitter ça peut venir de pleins d'autres choses. tout n’est pas forcément a mettre dans le même panier. D'ailleurs depuis le dernier patch tout semble fonctionner correctement.

Sinon c’est dommage que tu ne sois pas intervenu lorsqu'on avait justement besoin de personnes pour signaler les mêmes problèmes et donner des infos supplémentaires qui pouvaient aider le support.

romainovh
04/10/2016, 12h58
Bonjour,

J'ai suivi cette discussion sans intervenir, car je ne rencontrait pas beaucoup ce problème, hormis sur les logs.

Cependant, ce midi 04/10/2016 (entre 12h35 et 12h42), mon Firefox m'a refait "La connexion avec logs.ovh.net a été interrompue pendant le chargement de la page.".
Plusieurs fois...

J'ouvre une autre discussion avec un point que je n'espère pas lié aux derniers patchs.
https://forum.ovh.com/showthread.php...-les-login-mdp

J'ai de temps en temps l'erreur de chargement des js ou css sur d'autres sites comme Lemonde ou twitter... je ne pense pas qu'ils chez ovh

vcasse
04/10/2016, 12h51
Bonjour Thierry,

Je comprend ton sentiment.

Nous avons eu de réelles difficultés à reproduire ce bug. Comme indiqué, il se produit lors de conditions complexes à reproduire (latence spécifique, périodes de charges, comportement des navigateurs...). C'est pour cela que nous avons mis du temps à l'identifier, mais aussi pour le résoudre.

Bien entendu, nous avons ajouté des sondes qui reproduisent ce comportement précis afin d'éviter qu'il ne se reproduise.

Nous sommes désolé du temps de traitement de ce bug, et vous remercions d'avoir pris le temps de tester et de nous faire des feedbacks tout au long de cette période.

Cordialement,
Vincent

thierryla
04/10/2016, 11h43
Bonjour

Le problème semble réglé et j'en remercie chaleureusement TeamOVH.

J'en garde toutefois gros sur la patate.

- Le problème est apparu début juillet mais il a fallu attendre début septembre pour qu'OVH en ait connaissance, par ses clients. Pourquoi OVH n'a-t-il pas des bots qui monitorent certains sites web, pour les surveiller comme le fait un utilisateur lambda ? Une telle démarche ne peut être remplacée par les outils de supervision des ressources.

- Une fois le problème identifié, il a encore fallu attendre plus d'un mois pour le résoudre.

- Une tâche n'a été ouverte sur http://travaux.ovh.net/?project=4 que lorsque la solution a été trouvée. Ce n'est pas respectueux envers les nombreux webmestres qui se demandaient si le problème venait d'eux ou d'OVH.

Cordialement

Thierry LA

thierryla
03/10/2016, 16h21
Bonjour
Je teste de temps en temps depuis une heure, en direct et via Pingdom, et pour l'instant tout va bien.
Merci.

vcasse
03/10/2016, 15h45
Citation Envoyé par saxgard
Bonjour

Premiers essais sur 3 sites différents et à priori tout est ok. Je testerais encore pendant 2-3 jours afin de le confirmer et que ce patch n'a pas ajouté un autre problème .

Merci beaucoup en tout cas.

Ca veut donc dire qu'il faudra être vigilant lorsque de nouvelles protections anti-ddos seront mises en place
On ajoute les tests pour que ce type de cas ne se reproduise pas

saxgard
03/10/2016, 15h03
Bonjour

Premiers essais sur 3 sites différents et à priori tout est ok. Je testerais encore pendant 2-3 jours afin de le confirmer et que ce patch n'a pas ajouté un autre problème .

Merci beaucoup en tout cas.

Ca veut donc dire qu'il faudra être vigilant lorsque de nouvelles protections anti-ddos seront mises en place

vcasse
03/10/2016, 14h42
Bonjour à tous,

Nous venons de déployer le patch industrialisé en production.
Est ce que vous vouyez encore des erreurs ?

Cordialement,
Vincent

saxgard
03/10/2016, 13h11
Bonjour

Merci pour ces explications , pourvu que ca soit le dernier patch et qu'il mettra fin définitivement à ce problème pour que nos sites puissent reprendre une activité normale ^^

vcasse
03/10/2016, 12h33
Citation Envoyé par thierryla
Bonjour

Super. Mais du coup on aimerait bien savoir quel était le problème technique. Surtout s'il nécessite un patch déployé individuellement pour chaque site (puisque vous l'avez testé d'abord sur Sitacados). Mais je ne comprends pas comment c'est possible, vu qu'on est sur une infrastructure mutualisée...
Sur Performance 1, je crois que chaque site a un conteneur avec un serveur HTTP, mais pas sur les Perso et Pro...

Ce patch résout-il le bug ? Ou se contente-t-il de le contourner, en forçant le rechargement des fichiers ayant subi un ERR_CONENCTION ? Comme semble d'ailleurs le faire Firefox (mais pas Chrome....)

Cordialement
Thierry
Bonjour,

En vérité, nous avons testé ce patch sur le cluster où se trouvait sitacados. Il résoud le bug de "reset de connexion TCP" qui provoquait les erreurs de chargement de JS / Img / CSS sans le contourner.

On a identifié un problème dans l'anti ddos qui pouvait bloquer alétoirement certaines requêtes à tort lorsque de multiples requêtes TCP sont lancées en paralléle (lors du chargement de plusieurs fichiers JS par exemple). Si c'est cela, il est dépendant de multiples facteurs tel que la charge des serveurs ou encore la latence des requêtes, ce qui rend son apparition trés aléatoire.

On espère déployer ce patch en production en début de cette semaine.

Cordialement,
Vincent

saxgard
03/10/2016, 12h27
Bonjour

Merci @vcasse, pourriez vous également me confirmer que ce slignes dans me slogs web correspndent a des tests de votre côté sur mon site : [30/Sep/2016:14:56:43 +0200] "GET / HTTP/1.1" 200 23346 "-" "DotBot"

A priori l'adresse IP vient d'OVH

thierryla
03/10/2016, 12h01
Citation Envoyé par vcasse
Bonjour,

Effectivement, nous avons désactivé le patch en début de soirée.
Ce qui confirme que nous avons trouvé l'origine du soucis.

L'industrialisation du patch est en cours. Il demande un peu de développement mais on pense réussi à le déployer dans la semaine.

Cordialement,
Vincent
Bonjour

Super. Mais du coup on aimerait bien savoir quel était le problème technique. Surtout s'il nécessite un patch déployé individuellement pour chaque site (puisque vous l'avez testé d'abord sur Sitacados). Mais je ne comprends pas comment c'est possible, vu qu'on est sur une infrastructure mutualisée...
Sur Performance 1, je crois que chaque site a un conteneur avec un serveur HTTP, mais pas sur les Perso et Pro...

Ce patch résout-il le bug ? Ou se contente-t-il de le contourner, en forçant le rechargement des fichiers ayant subi un ERR_CONENCTION ? Comme semble d'ailleurs le faire Firefox (mais pas Chrome....)

Cordialement
Thierry

vcasse
03/10/2016, 11h15
Bonjour,

Effectivement, nous avons désactivé le patch en début de soirée.
Ce qui confirme que nous avons trouvé l'origine du soucis.

L'industrialisation du patch est en cours. Il demande un peu de développement mais on pense réussi à le déployer dans la semaine.

Cordialement,
Vincent

thierryla
30/09/2016, 22h43
Citation Envoyé par saxgard
J'imagine que le patch a donc été retiré pour le week end ? Et dans ce cas ça montrerait bien qu'il est efficace quand il est en place. Par contre si il est toujours en place au moment ou j'ai fait ces tests...
TeamOVH n'aurait quand même pas oublié de retirer un patch "instable" avant de fermer à clé la porte du datacenter pour partir en week end !

En tout cas, j'ai testé environ 15 à 20 fois fois ton site, en direct et via Pingdom, et, pendant la période où il était censé être patché, je n'ai pas vu d'erreur.

saxgard
30/09/2016, 21h32
Dans mes logs web uun peu avant 15h j'ai des tonnes de lignes suivantes :

www.sitacados.com - [30/Sep/2016:14:56:43 +0200] "GET / HTTP/1.1" 200 23346 "-" "DotBot"

Est-ce en rapport avec les tests que vous avez fait en interne chez OVH ? l'IP commence par 46.105

saxgard
30/09/2016, 20h59
Alors j'ai quand même fait une vérification à 20h58 et j'ai a nouveau eu le probleme :

Premier essai :
https://tools.pingdom.com/#!/pNYP8/h....sitacados.com
Trosième essai :
https://tools.pingdom.com/#!/bCFxgH/....sitacados.com

J'imagine que le patch a donc été retiré pour le week end ? Et dans ce cas ça montrerait bien qu'il est efficace quand il est en place. Par contre si il est toujours en place au moment ou j'ai fait ces tests...

thierryla
30/09/2016, 17h50
@Saxgard
Moi aussi j'ai fait un tas d'essais sur ton site, en direct ou via Pingdom, et pas de souci, ça marche...

Merci à TeamOVH.
Quand je pense qu'après trois mois de bug, je vais enfin (sans doute) avoir mon site OVH qui tourne comme mes sites chez XXXXX.

saxgard
30/09/2016, 17h40
Bon bin de mon côté j'ai fait des dizaines d'essais avec pingdom RAS, j'ai un peu surfer sur mon site RAS (mais de toute façon en surfant c’est plus difficile à identifier)
J'ai tenté un "Explorer comme Google" RAS et j'ai également fait une dizaine de tests sur GTmetrics, idem rien à signaler. A priori c'est du tout bon, sauf si j'ai eu de la chance (ou de la malchance) de ne pas tomber sur l'erreur.

j'avais pas vu qu'on apparaissait enfin dans les travaux

imalcom
30/09/2016, 17h38
Bonjour,

merci à Saxgard d'avoir ouvert cette nouvelle discussion, avec le titre et la synthèse qui va bien, des soucis que nous rencontrons, chargement aléatoires des css, js et images sur nos sites hébergé par ovh.

Perso j'ai migré tous mes autres sites, ne me reste que le perf2014x1 que je boost chaque mois en x2. Sur ce plan, pour ne plus subir le probleme de err_connection_reset, j'ai activé il y a quelques jours le cdn 17 pop, et il est très rare que mes css, js et images ne se chargent pas. J'attend encore quelques jours de voir si ovh résoud enfin le probleme, et si ce n'est pas le cas je migrerai aussi le perf2014, ce probleme n'a que trop duré.

Merci en tout cas à Vcasse d'avoir fait avancer les choses. Je vois dans le ovh task que notre probleme est enfin pris en compte : http://travaux.ovh.net/?do=details&id=20629

En esperant que cette semaine prochaine ce probleme soit du passé, bon week-end à tous.

thierryla
30/09/2016, 16h16
Citation Envoyé par vcasse
Bonjour,

lesandroides.net n'est pas concerné par le patch de cet après midi. C'est donc normal que le probléme soit reproduit.
Oui j'avais bien compris....

Citation Envoyé par vcasse
@thierryla : Je pense que vous tombez dans le soucis que nous pensons avoir identifié (et que nous testons actuellement). C'est pour cela que vous n'avez pas ressenti de différence.
Et pour le soucis qui a disparu en début de semaine : le patch du 16 septembre a été redéployé sur votre cluster en début de semaine suite à une mauvaise configuration observée tardivement. C'est pour cela que vous n'avez vu la différence que récemment.
Ha ça expliquerait...

Bon ben je vais tester sitacados de temps en temps jusqu'à 18h...

saxgard
30/09/2016, 16h06
Parfait merci, je vous tiens au courant avant 18h et fait mon nécessaire pour tester au mieux le site de mon côté

vcasse
30/09/2016, 16h03
Citation Envoyé par saxgard
En tout cas je pense d'apres mes premières tests que vous tenez le bon bout ^^
je vais attendre un peu pour les espacer et je donnerais mon verdict vers les 17-18h si c'est pas trop tard pour le retirer ensuite avant le week end ?
Oui, on coupera pas le patch avant 18h

Cordialement,
Vincent

saxgard
30/09/2016, 15h58
En tout cas je pense d'apres mes premières tests que vous tenez le bon bout ^^
je vais attendre un peu pour les espacer et je donnerais mon verdict vers les 17-18h si c'est pas trop tard pour retirer ce patch ensuite avant le week end ?

vcasse
30/09/2016, 15h51
Bonjour,

lesandroides.net n'est pas concerné par le patch de cet après midi. C'est donc normal que le probléme soit reproduit.

Sur sitacados, nous désactiverons le patch en fin d'après midi car nous ne le jugeons pas assez stable pour fonctionner sans surveillance accrue. Mais si les résultats sont corrects, nous espérons le déployer la semaine prochaine

@thierryla : Je pense que vous tombez dans le soucis que nous pensons avoir identifié (et que nous testons actuellement). C'est pour cela que vous n'avez pas ressenti de différence.
Et pour le soucis qui a disparu en début de semaine : le patch du 16 septembre a été redéployé sur votre cluster en début de semaine suite à une mauvaise configuration observée tardivement. C'est pour cela que vous n'avez vu la différence que récemment. Désolé pour ce contre temps

Cordialement,
Vincent

saxgard
30/09/2016, 15h38
Bonjour

Tout d'abord merci pour ce compte rendu. Je vais effectuer une batterie de tests sur Sitacados et vous tenir informé. Je voudrais éviter de donner une réponse hâtive et crier victoire trop tôt

@thierryla : si pour lesandroides.net je suis tombé sur le probleme :
https://tools.pingdom.com/#!/2ODav/h...sandroides.net

Je continu de tester pour sitacados, ça semble plutôt prometteur. je donnerais un premier verdict en fin d'aprem

@thierryla et @Imalcom n'hésitez pas a faire des tests également et faire une capture si vous voyez le pb sur sitacados.

thierryla
30/09/2016, 15h25
Citation Envoyé par vcasse
- 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é.
Je n'ai pas constaté de baisse de la fréquence du bug pendant l'été, sur mon site http://www.lesandroides.net/

Citation Envoyé par vcasse
- 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.
Je n'ai pas non plus constaté de baisse de la fréquence du bug à partir du 14 septembre

Citation Envoyé par vcasse
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.
Je n'ai pas non plus constaté de baisse de la fréquence du bug à partir du 16 septembre.
Mais depuis environ 3 jours (27 septembre donc), je ne vois plus de "ce site est indisponible" pendant 1/2 s, juste avant que le site ne s'affiche.

Citation Envoyé par vcasse
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.

Actuellement, nous n'arrivons pas à reproduire le soucis sur pingdom par exemple. Vous confirmez ?
Je confirme, via pingdom sur sitacados, pas de ERR_Connection RESET.
Sur un seul essai.
Mais pas non plus sur http://www.lesandroides.net/ alors que j'ai encore eu des CSS mal chargé plusieurs fois depuis ce matin.

Cordialement
Thierry

vcasse
30/09/2016, 15h11
Bonjour à tous,

Tout d'abord, merci à vous d'avoir réuni les informations. On continue de scruter les topics de maniéres réguliéres et le travail de synthèse ici est pratique .
Depuis nos derniers patchs, nous avons continuer à chercher l'origine des soucis.

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.

Actuellement, nous n'arrivons pas à reproduire le soucis sur pingdom par exemple. Vous confirmez ?

Si le résultat de ce test est positif, nous le désactiveront pour le week end avant d'industrialiser son déploiement la semaine prochaine.
Merci à tous pour vos feedbacks et vos tests.

Cordialement,
Vincent

thierryla
30/09/2016, 11h55
Team OVH, vous abandonnez les recherches ?
On a le droit de savoir.
Merci de nous répondre.

Cordialement
Thierry

saxgard
29/09/2016, 18h56
Vu que les "site inaccessible" et les problèmes de css etc. sont apparus au même moment il y a de forte chance qu'ils soient étroitement liés, à moins qu'il s'agisse d'une pure coïncidence et qu'il y a donc 2 problèmes distincts.

thierryla
29/09/2016, 17h57
Citation Envoyé par saxgard
idem je m'étais également fait la remarque, mais je préférais attendre un peu avant pour en être sur. Mais bon vu que j'en ai eu il y a 2 jours et qu'à priori ils ne bossent plus dessus je ne vois pas pourquoi ca partirait comme par enchantement.
Il y avait peut-être 2 problèmes indépendant et ils en ont résolu un. Peu probable mais bon. Surtout que le "ce site site inaccessible" ressemble au symptôme d'un ERR_Connection sur l'index.php du site, Alors que les problèmes de CSS ou d'images ressemblent à un ERR_Connection sur ces fichiers. Donc toujours la même erreur.

saxgard
29/09/2016, 17h00
idem je m'étais également fait la remarque, mais je préférais attendre un peu avant pour en être sur. Mais bon vu que j'en ai eu il y a 2 jours et qu'à priori ils ne bossent plus dessus je ne vois pas pourquoi ca partirait comme par enchantement.
Quoi qu'il en soit il y a effectivement toujours des soucis concernant les css, js et images. j'ai même l'impression que les problèmes avec les images sont plus fréquents qu'avant. je continue de mon côté à vérifier

thierryla
29/09/2016, 16h22
A noter que depuis 2 ou 3 jours, je n'ai pas vu "ce site est site inaccessible" pendant 1/2 s.

Mais les problèmes de CSS et parfois d'images manquantes sont toujours aussi fréquents.

saxgard
29/09/2016, 14h48
Bonjour

C'est important de préciser que l'on observe plus facilement le problème sur Chrome, ce qui ne signifie pas que ça touche uniquement chrome. On peut également facilement observer le problème sur Siafari (Ipad) et via différents outils (bots) tels que gtmetrics, pingdom ou googlebot. Sur firefox ca semble plus difficile a priori, ce navigateur doit surement se comporter différemment en cas d'erreurs de chargement ou de err_connection_reset.

Tous ceux qui passent sur le forum et qui ont constaté à plusieurs reprises des problèmes de chargement d'images, de css et js ou l'erreur "site web inacessible" pendant 1/2 seconde, doivent prendre conscience que ca ne vient pas de chez eux ni de leur site.

thierryla
28/09/2016, 23h50
Bonjour
J'ai constaté ces problèmes, uniquement sous Chrome, sur plusieurs sites OVH, dont le mien, mais aussi http://www.cecile-ducrot.net/ et même sur des sites de personnes venues solliciter le forum pour d'autres questions.

Je l'ai constaté de plusieurs endroits en France cet été (Nice, Vosges, Alpes). Et je le constate très fréquemment, de chez moi, sur mon PC sous Windows et sur ma tablette Android, aussi bien par Numericable que par Free (j'ai deux accès Internet chez moi).

J'ai demandé à mes amis Facebook de tester mon site http://www.lesandroides.net/. Sur 8 réponses :
- 4 n'ont rien vu (un seul essai)
- 3 ont vu le problème au premier essai
- 1 l'a vu au 2eme essai

J'ai copié mon site sur un hébergement Gandi (sur une autre URL, donc), où je ne rencontre jamais le problème.

saxgard
28/09/2016, 23h43
Merci Gaston_Phone, j'espère ne pas faire tout ça pour rien. D'autant plus que je le fait pour moi mais egalement pour le très grand nombre de clients ( si ce n'est tous à des degrés différents) certainement concernés par ça.

Gaston_Phone
28/09/2016, 23h16
Belle synthèse, qui je l'espère, sera lue attentivement par les membres de la Team OVH.

saxgard
28/09/2016, 22h46
Présentation du problème*:

Sur mes sites et sur de nombreux autres sites hébergés chez OVH (dont le forum d'OVH) nous constatons régulièrement les dysfonctionnements suivants*:

  • Affichage de «*site web inacessible*» pendant ½ seconde avant le rechargement de la page. Erreur correspondant à un err_connection_reset
  • Des problèmes aléatoires d'affichages des fichiers CSS, js et des images
  • Ce problème touche tous types de sites (wordpress ou non) et une bonne partie du réseau OVH
  • Il semble plus facilement identifiable sur Chrome et Safari ou par les bots
  • Le CDN activé semble réduire les erreurs


Ces problèmes semblent apparaître le plus souvent lors d'un premier accès sur nos sites ou après un certain temps sans y avoir accédé. Mais ça reste très aléatoire. Nos visiteurs ainsi que les bots (moteurs de recherche etc.) sont affectés par ce dysfonctionnement. Ce qui peut nuire à notre image, diminuer les revenus pour certains, et peut être même influencer nos positions sur les moteurs de recherche.

Victime de ces dysfonctionnement*?

Alors non, ca ne vient pas de votre navigateur, de votre site ou de votre FAI. N'hésitez pas à vous manifester ici. Indiquez votre URL, cluster, FAI, filer et si le CDN est activé. Donnez toutes informations pouvant être utiles pour le support (captures d’écran, heure exact ou ça c’est produit etc.). Si vous avez des outils ou des techniques pour identifier facilement le problème n'hésitez pas à les fournir également.

Liste des clients ayant déjà signalés ce bug*:

lfilleur
insidebasket
imalcom
lulu3728
Leuf
thierryla (*http://www.lesandroides.net/* , cluster005, : filerz436 , *Numéricable et Free )
Fred (*cluster 002 ( offfre perf2014x1 ) filer 232 NDD .agenda-sports.fr FAI free mobile)
kingkurt
valaisan (sur 2 mutualisés)
Persilou (aquitaineonline.com, perf2014x1, fiiler 102, cluster 007)
saxgard (http://www.sitacados.com, 90plan, cluster 002, pas de CDN activé, filer 43, FAI*: SFR)
buddy
Picoteur*
l'erreur «*err_conection_reset*»*:

http://img4.hostingpics.net/pics/858...accessible.jpg
http://www.agenda-sports.fr/divers/S...1-00-43-11.png

Probleme de chargement des CSS, images etc.:

http://couscous-thierry.chez-alice.f...927-135055.png
http://www.lesandroides.net/lesandroides.jpg
http://img4.hostingpics.net/pics/306277ovhforumcss.jpg
http://img4.hostingpics.net/pics/377...educrotovh.jpg
http://img15.hostingpics.net/pics/28...isponibles.jpg

Tests Via Pingdom

https://tools.pingdom.com/#!/biD2my/...maginance.com/
https://tools.pingdom.com/#!/dxBMgT/.../forum.ovh.com
https://tools.pingdom.com/#!/bIYuPB/....sitacados.com
https://tools.pingdom.com/#!/cLztg8/...sandroides.net

Oui Pingdom est crédible :
https://forum.ovh.com/showthread.php...l=1#post679782

Tests via « Explorer comme Google » :

http://img15.hostingpics.net/pics/97...mmegoogle2.jpg
http://img15.hostingpics.net/pics/97...mmegoogle2.jpg

Tests Via GTmetrics

https://gtmetrix.com/reports/www.les...s.net/VgANVBwZ
https://gtmetrix.com/reports/www.sitacados.com/nsmlWyJf

Tests Via keycdn

http://img4.hostingpics.net/pics/287...sandroides.jpg
http://img4.hostingpics.net/pics/725...nsitacados.jpg
http://img4.hostingpics.net/pics/353...dnforumovh.jpg

Tentatives de Patchs :

https://forum.ovh.com/showthread.php...l=1#post679058
https://forum.ovh.com/showthread.php...l=1#post679224
https://forum.ovh.com/showthread.php...l=1#post679536
https://forum.ovh.com/showthread.php...l=1#post679715


Ce topic à pour but de faire suite à celui-ci https://forum.ovh.com/showthread.php...ndes-Wordpress avec un titre plus explicite et un résumé concis des problèmes constatés.
Cet ancien topic pèse plus de 327 posts et 8000 consultations et plus d'une douzaine de clients (le haut de l'iceberg) se sont plains des mêmes problèmes restés actuellement sans solution malgré 3 patchs mis en place par le support d'OVH qui peine malheureusement à reproduire les erreurs.

Un problème qui perdure depuis environ 3 mois.