ralentissement dans les temps d'accès

[plow]

Bonjour, pour mes deux sites fncta-midipy.fr et teplitz-theatre.net check my website m'indique depuis quelques jours des temps d'accès moyens augmentés de 50 à 100% de 200 ms à plus de 400ms. En cinq ans, ce n'était jamais arrivé. Par ailleurs je ressens un ralentissement dans l'accès à l'administration de ces sites.Do you Check me signale par ailleurs plusieurs slow chaque jour. Pas vraiment grave pour l'instant mais ça m'inquiète pour la suite. Suis-je le seul concerné ?

Bien cordialement

[Invité]

Hello,

J'ai également des soucis de ralentissement depuis quelques temps maintenant (je tourne autour de 2.2 secondes avec DoYouCheck et 70 slows par jour). L'équipe est au courant (enfin tout du moins pour mon cas) et essaye de trouver des solutions pour pallier à ce soucis. D'après ce que j'ai compris c'est assez compliqué de déterminer la cause. Ils cherchent cependant des solutions !

Espérons que ça s'arrange !

[Invité Simon D.]

Bonjour,

Nous avons effectivement eu quelques retours de clients (quelques = 5/6 en comptant tickets + chat) pour des lenteurs.

N'hésitez surtout pas à ouvrir des tickets si vous êtes concerné, cela sert à @Benoît GEORGELIN pour investiguer et faire des tests.

A ma connaissance, vous êtes le seul à nous remonter spécifiquement des ralentissements sur la partie administration.

[plow]

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

[Invité]

@plow

Pourriez-vous me donner l'URL du site que vous utilisez pour monitorer ? "Check your website " me retourne pas mal de sites sur google.

J5utilise déjà DoYouCheck en version d’évaluation et je cherche une alternative à la fin de la période d'essai. UptimeRobot est pas mal mais je n'ai pas d'historique supérieur à un mois.

Modifié 19 août 2017 par Alex

[Invité Simon D.]

il y a une heure, Alex a dit :

Pourriez-vous me donner l'URL du site que vous utilisez pour monitorer ? "Check your website " me retourne pas mal de sites sur google.

https://checkmy.ws/fr/ il me semble, lequel est payant.

En gratuit il y a https://www.pingdom.com/free, je ne connais pas ses limitations.

[Invité]

Merci ! Effectivement, je cherche une solution gratuite.

J'utilise UptimeRobot mais l'historique s'arrête à 1 mois. Je vais voir pour Pingdom, je crois que j'ai déjà un compte.

Le 16/08/2017 à 18:29, plow a dit :

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

Voici pour ma part pour le dernier mois avec Pingdom, les dates semblent correspondre. (même si je suis embêté depuis début juillet par une augmentation significative des temps d'accès):

 

[Invité Simon D.]

Il y a 12 heures, Alex a dit :

Voici pour ma part pour le dernier mois avec Pingdom, les dates semblent correspondre. (même si je suis embêté depuis début juillet par une augmentation significative des temps d'accès):

Merci pour le graphique, je l'ai remonté à @Benoît GEORGELIN.

De mon côté, j'ai été assez surpris de la différence de temps mesuré sur mon hébergement entre DoYouCheck et Pingdom (en édition gratuite), le second m'annonce un temps de réponse moyen double du premier !

La différence semble être que DoYouCheck vérifie depuis la France (OVH/Online) alors que Pingdom arrive des USA (Amazon Web Services).

[Simon]

Hello Alex/Simon,

En effet, les sites d'Alex sont monitorés depuis la France uniquement, via Scaleway et OVH. On peut ajouter une sonde à San Francisco sur ces sites pour voir si on se rapproche des temps d'accès de Pingdom Alex. Tu me diras, je l'ajouterai si tu veux.

Mais oui, clairement ici, le délai supplémentaire doit être dû à la traversée de l'Atlantique

[Invité]

Oui, Pingdom est plus long en général du fait de la localisation des serveurs, le plus proche pour un site français est Stockholm en suède. Après pour le graph que j'ai donné plus haut, je ne sais pas du tout quel serveur se charge de ça, je pense qu'il est aux USA parce que DoYouCheck m'annonce en moyenne 2,5s contre 3,5 pour Pingdom.

[Simon]

Je viens d'ajouter SF et Londres pour ton site, tu pourras comparer Alex.

[Invité]

Super, merci ! Effectivement, à l'instant:

[plow]

Le 16/08/2017 à 18:29, plow a dit :

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

La courbe de doyoucheck confirme.

[plow]

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

[plow]

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

[alexisju]

Même constat de mon côté, au quotidien sur plusieurs instances Wordpress hébergées sur Yulpa.
Les temps de chargement des pages a sensiblement augmenté ces dernières semaines. La différence est flagrante comparé à d'autres WP que je gère sur d'autres plate-formes...
Je reçois également de nombreuses alertes d'Uptime robot ces derniers jours  ...

 

[Lafuente]

Très pareil ici. Dommage que mon site ne soit jamais aussi réactif que le site yulpa...

Ce problème récurrent est malheureusement celui qui me fera héberger mon site sur un VPS assez rapidement...

Modifié 3 octobre 2017 par Lafuente

[Aurelien P.]

Bonjour, 

j'aimerais bien comprendre tout de même pourquoi des sites sur exactement la même infrastructure que celle sur laquelle sont vos sites, fonctionnent parfaitement bien avec des temps largement inférieur.... 

• http://pingdom.yulpa.io/857448 ~307ms 
• http://pingdom.yulpa.io/3304600 ~430ms
• http://pingdom.yulpa.io/3212764 ~525ms

On a vraiment en fonction des sites des temps de réponse très différent. Sachant que tout l'infrastructure est la même (les deux premiers là sont des WP) il y a quelque chose à faire coté applicatif....

Pour les temps remontés par DYC de 400-500 ms, clairement je ne vois pas où est le problème. Une variation de 100-200ms n'est pas anormale et on ne fera rien pour modifier cela

[plow]

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

[alexisju]

Pour ma part, je ne mesure pas tant le temps de réponse directe du site (ping), mais le temps de chargement des pages. Dans le backend WP, j'en suis souvent autour des 5 secondes (parfois c'est 3s - rarement en dessous -, mais je suis vite à plus de 8s en load).  J'obtiens ces mesures avec le debugeur réseaux de Firefox.

[Lafuente]

Bonjour Aurélien,

Pour moi également ce n'est pas le ping qui importe mais "l'expérience utilisateur". Et là je rejoins Alexis => le temps de téléchargement des pages est "long", même en back-office. Passer du temps à optimiser les images et le reste pour augmenter la fluidité d'un site a ses limites et encore faut-il en être conscient. Mr X n'optimise pas ses images par exemple.

Moi je pencherais pour un problème applicatif serveur ou sécurité... Car je viens de faire le test suivant :

Copie 1:1 d'un de mes sites internet sur un VPS SSD à 3€/mois (1vCore 2,4GHz, 2Go RAM et 10Go SSD). Distribution CentOS. Les résultats sont de loin sensibles... Sur le VPS les pages s'affichent, elles ne se "chargent" pas. Et idem en backoffice. Et je n'ai pas utilisé de module cache...

++

Manu

Modifié 3 octobre 2017 par Lafuente

[Adrien]

Moi je plains plus du tout depuis que j'ai plus mes énormes ralentissements qui se produisaient auparavant. En revanche, c'est vrai que les temps de réponse indiqués peuvent être intrigants au regard du type de site. Je viens de constater que moi (ultimaterra.fr), d'après pingdom, j'ai de moins bonnes performances qu'un site wordpress. Difficile à comprendre, surtout sans être connecté. Vous pouvez regarder le temps de génération de page en bas.

Mais comme je le dis, je me plains pas, je comprends qu'il fasse moyenner l'affaire. Je serais juste curieux de savoir ce qui peut influer ça.

 

Quoi qu'il en soit, comme le disait Aurélien, l'hébergeur n'est pas le seul responsable, il y a aussi le côté applicatif qui joue énormément (la preuve avec les tps d'accès très différents). Faut donc être vigilent là dessus et au niveau des plugins que vous mettez. C'est pas vraiment normal pour un site s'il a besoin d'une machine de guerre pour se charger.^^

Modifié 4 octobre 2017 par Adrien

[Benoît G]

Bonjour, 

Je pense qu'on devrait faire un article de blog pour expliquer plusieurs points importants liés à un mutualisé en général. Ce qui explique souvent les grandes différences entre mutu/dédié
Aussi, entre les mêmes sites d'un mutu, les configurations sont multiples, les impactes sur la performance aussi. 

Par exemple pour un hébergement mutualisé on va avoir des comportements différents avec:

- La version de PHP utilisée 
- La configuration de PHP et principalement open_basedir
- Le nombre de sous-repertoires ou est le htdocs .  Plus il y a de répertoires plus ca prendra du temps 
- Le nombre de domaine sur l'hébergement. Plus de domaine, plus de requêtes simultanées , moins de performance 

Ensuite, le site lui même :

- Nombre d'objet (local) par page (image, css, js, etc..) plus il y a d'objets, plus les impacts sont importants 
- Nombre d'object externe par page
- Session PHP ( en base de données VS sur disque)
- Moteur de cache ou pas 
- Gestion des "expires" sur les objets ou pas
- Utilisation de la base de données (requêtes SQL)
- Niveau de répertoire pour les éléments à charger (image,css,js) encore une fois, plus il y a de niveau , plus c'est long pour une requête. 

Globalement, je pense que toutes les personnes qui s'intéressent à la performance ont déjà connaissance de la majorité de ces aspects, mais il est bon de le mentionner

Au niveau performance des serveurs du mutualisés, chez yulPa, on est loin d'être surchargés. Il est clair que nous avons de plus en plus de clients mutualisés, mais tout est fait pour assurer la monté en charge comme il faut. 
Si l'on regarde sur les 12 derniers mois par exemple, on peut constater plusieurs cas au niveau des temps de chargement : 

- Ceux qui n'ont aucune différence 
- Ceux qui ont une légère augmentation 
- Ceux qui ont une légère diminution

Effectivement, on rencontre bien les trois cas de figure. 
Ce qui pénalise un client peut favoriser un autre justement à cause des paramètres de configuration de l'hébergement et ceux du site. 

Notre mutualisé doit répondre aux attentes de la majorité des clients, c'est certain que le temps de réponse et de chargement est important. 
Vos retours sont toujours pris en compte mais malheureusement, dans certains cas, il est possible que vous soyez dans un "entre-deux" qui fait que vous n'avez pas les performances que vous souhaitez.  Dans ce cas la, l'idée est de pouvoir vous proposer une solution permettant de répondre correctement à vos attentes. 

On est capable de vous proposer des solutions performantes, isolées avec leur propres ressources . C'est ce que nous faisons par exemple pour des besoins comme des boutiques en lignes , des sites qui ne tolèrent pas la moindre augmentation du temps de chargement et qui cherchent quelque chose de constant et de personnalisé. 

Si demain on vous propose une offre d'hébergement en dehors du mutualisé, avec un serveur web dédié et une base de donnée dédiée , seriez-vous intéressé ?
Sachant que les performances/impactes seront totalement différentes versus un mutualisé. 
On parle ici de quelque chose de plus adapté a certains besoins. 
Le mutualisé ne peut pas rivaliser avec une solution comme celle-ci, sinon le prix du mutualisé serait considéré comme bien trop cher pour espérer apporter des temps de chargement et de réponse identiques à une solution dédié .
Le mutualisé doit garder une stabilité et un temps de chargement acceptable, ce que nous faisons et c'est important. 
Comme le mentionnait Aurélien, des sites à fort trafic sont en moyenne à 300 ou 400 ms de chargement (pingdom) , sur la même plateforme que des sites qui ont 2 ou 3 secondes de chargement.  C'est pour nous des "aléas" du mutualisé suivant le contenu, les configurations client et les configuration de l'hébergement. 








 

[alexisju]

Bonjour,

Je suis partagé sur votre réponse. J'ai l'impression que la plupart des personnes qui s'expriment ici le font en connaissance de cause.
On connaît l'implication d'une plateforme mutualisée et la multiplicité des facteurs.

Pour ma part, je n'attends pas des performances top niveau, mais constate une dégradation sensible.
Mais 5-8 secondes en backend quand on crée un article WP n'est pas acceptable...

[Invité]

Merci Benoit pour ces précisions. Depuis nos longs, très longs échanges de juillet via un Ticket, j'ai un peu laissé tombé la chose depuis quelques semaines. Je me suis fait à l'idée que mon site malgré les innombrables optimisations que j'ai fait ne descendrait pas en dessous des 2 secondes de chargement en mutualisé chez vous. (Pour être honnête, j'ai pris 1 mois un VPS chez OVH à 2€ à des fins de tests, j'ai juste copier / coller le site pour tester, j'étais en dessous des 400 MS de chargement, une vraie fusée !).

Vous m'aviez déjà  parlé il y a quelques mois d'un VPS mais je n'ai pas eu de news de votre part depuis, selon son coût, cela pourrait effectivement m’intéresser.