plow

Bonjour, Sur mon site, aussi bien en tant qu'admin qu'en tant que visiteur, avec firefox et chrome juste avant d'envoyer le message, vers 10h donc ; ça n'a heureusement, pas duré.

Message reçu pendant une bonne minute : La connexion avec le serveur a été réinitialisée pendant le chargement de la page. La page que vous essayez de consulter ne peut pas être affichée car l’authenticité des données reçues ne peut être vérifiée. Veuillez contacter les propriétaires du site web pour les informer de ce problème.

J'ai beau chercher, je ne trouve pas la section Utilisation des ressources Où se cache-t-elle ? ça y est j'ai trouvé mais même erreur côté fichiers

Ce sujet ayant été visionné de nombreuses fois, il vaut peut-être la peine de dire où j'en suis. J'ai ouvert un ticket qui n'a pas abouti et que j'ai donc clôturé. La seule solution que j'ai trouvée, ne souhaitant pas quitter yulpa, est de changer de programme de cache. Et effectivement, plus d'erreurs depuis. Mais les utilisateurs de Comet cache, en tout cas de Comet cache pro doivent savoir que la même erreur peut leur advenir ici

C'est à dire abaisser ce que le manager appelle le seuil de quarantaine, c'est ça ? Je vais tester

Depuis cette intervention, j'ai quelques spams évidents qui arrivent jusqu'à Zimbra... c'est dommage, car jusque là, c'était parfait

Bonjour et très bonne année Voici la réponse reçue sur le forum de Shark (Comet cache pro) : @plow Unfortunately this is a host-related issue. Some web hosting companies use file systems that cause problems with atomically reading, writing, and deleting files in the cache directory and when one of those problems occurs, and Comet Cache is unable to delete or rename files, you get this error. My recommendation is to either try a different web hosting company or work with your hosting company to see if they can resolve the issue. Je préfèrerais de loin la deuxième solution et vais donc relancer le ticket ouvert à ce sujet

Bonjour et merci pour la réponse Je vais interroger le développeur. Mais j'avoue que "race condition" et NFS ne veulent pas dire grand chose pour moi. L a fréquentation de mon site n'est pas si importante que ça et votre hypothèse m'étonne un peu. Comet cache est un plugin très répandu et il y a sûrement d'autres utilisateurs sur ce forum. Quelqu'un aurait-il déjà eu ce type de problème ?

Lorsque je veux vider le cache de mon site fncta-midipy.fr (cache créé par le plugin comet cache pro), j'ai régulièrement le message d'erreur joint. Ce message disparaît à la deuxième, troisième ou quatrième tentative et le cache se vide normalement. J'ajoute qu'il apparaît aléatoirement mais me semble lié à des problèmes de ralentissement du serveur pendant l'administration du site beaucoup plus fréquents qu'auparavant. J'ai ouvert un ticket mais pour l'instant mon problème reste entier. Quelle est cette "fatal error" et comment l'expliquer ? Est-ce que quelqu'un peut m'aider à comprendre ce message ?

En ce qui me concerne, je n'utilise pas Total Cache mais Comet Cache Pro qui est configuré pour ne pas utiliser le cache lors des accès administrateur. Et ça fonctionne sans problèmes. J'ai un minimum de plugins et pas question de s'en passer. Ceci dit, quand ça ne va pas, il faut le dire mais quand ça va bien, il faut le dire aussi. Et là, après les incidents d'hier, pour la première fois depuis un bon moment, le temps d'accès moyen utilisateur sur 24h à mes sites est repassé sous les 300 ms et j'ai longuement travaillé à l'admin sans ralentissements Bravo Yulpa, ça prouve bien qu'on peut le faire !

Désolé si ça n'était pas clair. La question principale est : comment expliquer que l'administration d'un site wordpress qui se faisait avec une rapidité et une réactivité tout à fait correcte puisse devenir inconfortable : temps de chargement des pages irrégulier, parfois très long, nécessité assez souvent de recharger les pages après changements, problèmes dans les mises à jour de plugin ... cela, alors que le site n'a connu aucun changement structurel notable. Ceci ne peut évidemment pas se prouver par des tests type doyoucheck ou Gtmetrix mais c'est ce que je constate Question supplémentaire : le passage au https peut-il être un élément d'explication au ralentissement, très relatif de 200/250ms dans le temps d'accès utilisateur (celui que mesurent les tests)

Il me semble avoir lu que vous aviez un ou des serveurs dédiés à l'administration, c"est peut-être de ce côté là qu'il faudrait regarder. Les pings que vous citez ne rendent pas compte de l'accès administrateur (forcément hors cache) qui est ce qui me soucie. Par ailleurs, la seule évolution de mes sites ces derniers mois a été (grâce à Yulpa ) le passage en https. Cela pourrait-il expliquer les 200/250 ms en plus de temps d'accès pour un même site ?

J'entends parfaitement tout ce qui se dit. Mais tout cela était déjà vrai il y a 3mois, 6 mois, 1 an et mes sites n'ont fondamentalement pas changés entretemps, les temps d'accès et de chargement moyens eux ont changé, en moins bien, surtout pour l'administration. Je suis client depuis 5 ans, petit client avec un site d'association qui n'aura pas les moyens de se payer du dédié. Le site est actif, j'y travaille tous les jours et, malgré des incidents, j'ai toujours eu, jusqu'à la dernière période, le sentiment de travailler confortablement. J'aimerais retrouver ce sentiment

Bonjour, Il est vrai que des variations de 100-200 secondes ne sont pas bien graves. Pour ma part, ce qui me frappe c'est que l'augmentation de 200 secondes semble durable, sinon définitive, marquant ainsi une tendance. Mais ce qui m'embête davantage, c'est ce qui se passe au niveau de l'administration : ralentissements aléatoires au milieu du travail, nécessité de plus en plus fréquente de recharger les pages après un changement, gros problèmes de cache, une certaine instabilité donc que je ne connaissais pas, il y a encore quelques mois. Cela reste certes gérable pour le moment mais m'inquiète un peu

Malheureusement, le temps d'accès s'est mis à remonter. Il est maintenant à plus de 400ms. Les courbes Doyoucheck pour mes deux sites le confirment. En même temps, l'administration reste trop lente

Je confirme qu'il y a eu du 5 au 7 septembre une nette baisse du temps d'accès mais qui n'a pas duré. Je n'ai jamais été à 1 seconde mais j'ai été à moins de 2 pendant ces trois jours pour remonter à plus de 3 puis à frôler les 4 secondes. Et l'administration reste nettement plus lente qu'elle ne l'était avant l'été et ça c'est plutôt embêtant

Plus d'incidents aujourd'hui , mais le temps d'accès moyen qui avant la journée d'hier était redescendu à moins de 300 ms est remonté à plus de 400 et l'administration est clairement plus lente qu'avant Mais je garde bon espoir !

D'après la réponse que j'ai reçue, la journée d'hier est à oublier et ça devrait aller mieux aujourd'hui. Croisons les doigts

Gros ralentissement de l'administration de mes sites aujourd'hui, jusqu'à l'impossibilité de me connecter. J'ai un ticket ouvert mais pas encore de réponse

Bonne nouvelle, la courbe redescend. Aujourd'hui elle est presque à son niveau d'avant

En effet c'est corrigé

Bonjour Sur la page https://yulpa.io/domaines.html : Warning: Mise a jour des domaines: impossible de creer le backup du fichier XML in /datas/www/www.yulpa.io/includes/functions.inc.php on line 167 message répété 6 fois. La suite semble fonctionner normalement

Plus de deux heures de coupures ce matin et je ne vois rien dans les travaux qui expliquerait cela ? L'intervention sur le Filer ZFS devait prendre quelques secondes. Est-ce cela ?

La courbe de doyoucheck confirme.

Je vous joins la courbe du temps d'accès Check your website sur un mois qui rend bien compte de l'augmentation du temps d'accès depuis, en gros, le 8 août ; ça semble d'ailleurs redescendre un peu depuis hier. Et de toute façon, ce n'est pas bien grave de passer de 250 à 350 ms, si ça s'arrête là. Mais je confirme aussi un certain ralentissement dans l'accès à l'administration (pas dans l'administration elle-même) depuis la mi juin