Aller au contenu
plow

ralentissement dans les temps d'accès

Recommended Posts

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

  • Upvote 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Désolé mais au vue des réponses, je repose donc la même question... 

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

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

Je ne parle pas là de ping ou de VPS ou autre mais bien de sites qui sont exactement sur la même infrastructure que vous. 

Partager ce message


Lien à poster
Partager sur d’autres sites

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 ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut Aurélien,

Il est évident que l'applicatif web est important. Mais je pense que les personnes ici présentes en sont conscientes et essaient d'en tenir compte. Moi je peux assurer en tenir compte et essayer d'optimiser mon applicatif.

Pour le montrer, le troisième site que tu proposes, ultimaterra, nécessite 145 requêtes pour charger 2.85Mb de datas !

Mon propre site charge 1.86Mb en 71 requêtes. Je ne comprends donc pas pourquoi tu cite ce site en référence dans ta question. Pour le mauvais exemple ?

Aurais-tu un exemple de site prestashop 1.6.1 afin que je puisse comparer si mon "applicatif" déconne ?

Par avance merci,

Manu

 

 

ultimaterra.jpg

megasquirt.jpg

Partager ce message


Lien à poster
Partager sur d’autres sites

Et pour les 2 sites wordpress :

 

blog_nt.thumb.jpg.ff77431132822b8ca9547a4ce402b1ee.jpg

blogmotion.jpg

Dans ces 4 exemples, ce n'est pas le ping qui pour moi a de l'importance, mais le "Fully Loaded Time". J'ai constaté que ce temps de chargement de page est surtout impacté par le TTFB (Time To First Bit). Ce temps est effectivement maitrisable du coté de l'applicatif web en utilisant des techniques de cache, mais c'est complexe. N'y a t'il pas moyen de l'optimiser de votre coté ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Accessoirement, vous avez un bug dans l'affichage du temps depuis la dernière réponse sur votre forum lorsque l'on utilise une tablette apple. Il est écrit "%d" au lieu du temps ;-)

Partager ce message


Lien à poster
Partager sur d’autres sites

Enfin pour conclure, il est notable que sans modification de l'applicatif, les temps d'accès varient dans le temps. Il semble y avoir une période "lente" assez quotidienne entre 19h et 21h, et on constate une variation régulière des temps de chargement d'un jour à l'autre.

Benoit dit :

Le 04/10/2017 à 15:32, Benoît GEORGELIN a dit :

Au niveau performance des serveurs du mutualisés, chez yulPa, on est loin d'être surchargés

Il est donc important de se demander pourquoi on constate des écarts significatifs sur un même site, donc a applicatif égal, dans le temps..

Je souhaite ce débat constructif ;-)

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 1 heure, alexisju a dit :

@Aurélien PONCINI quelle est la question, au juste?

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)

 

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 8 minutes, Lafuente a dit :

Enfin pour conclure, il est notable que sans modification de l'applicatif, les temps d'accès varient dans le temps. Il semble y avoir une période "lente" assez quotidienne entre 19h et 21h, et on constate une variation régulière des temps de chargement d'un jour à l'autre.

Benoit dit :

Il est donc important de se demander pourquoi on constate des écarts significatifs sur un même site, donc a applicatif égal, dans le temps..

Je souhaite ce débat constructif ;-)

Il y a une différence dans la journée versus la nuit  ou aux heures de pointe. Il y a du trafic plus important , cela à un impact sur le système de manière globale mais que je ne considère pas comme une "surcharge" .  C'est un comportement normal , plus il y a de connexion , plus le système travaille . On le constate bien la nuit oui c'est beaucoup plus calme et pourtant il n'y a pas de différence du simple au double la nuit versus le jour .  

Le débat est constructif ;)

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 3 minutes, plow a dit :

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

Oui, c'est bien la question que les clients se posent.
Mais je ne comprends pas bien que cette "question" provienne du prestataire de service... et soit adressée en retour aux clients.

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 57 minutes, Lafuente a dit :

Salut Aurélien,

Il est évident que l'applicatif web est important. Mais je pense que les personnes ici présentes en sont conscientes et essaient d'en tenir compte. Moi je peux assurer en tenir compte et essayer d'optimiser mon applicatif.

Pour le montrer, le troisième site que tu proposes, ultimaterra, nécessite 145 requêtes pour charger 2.85Mb de datas !

Mon propre site charge 1.86Mb en 71 requêtes. Je ne comprends donc pas pourquoi tu cite ce site en référence dans ta question. Pour le mauvais exemple ?

Aurais-tu un exemple de site prestashop 1.6.1 afin que je puisse comparer si mon "applicatif" déconne ?

Par avance merci,

Manu

On parlait ici du temps d'accès au site (qui est bon) et le site fonctionne très bien. Ta mesure est intéressante mais indique le temps pour charger toutes les ressources de la page. Il y a un tas de scripts qui sont lancés de façon asynchrone et qui ne ralentissent donc pas le chargement en lui-même.

Partager ce message


Lien à poster
Partager sur d’autres sites

@Benoît GEORGELIN merci pour cet éclaircissement. C'est effectivement le principe du mutualisé et je l'entends ainsi. Cependant il y a des variations que je ne m'explique pas que par l'augmentation des connexions simultanées. En effet le temps de chargement de la page n'est jamais régulier, mêmes à des heures de faible charge. N'y aurait-il pas des corélations possibles entres certaines tâches de l'infra (backup, resync, etc...) ? Vous semblez avoir un ou plusieurs reverse-proxy. N'y a t'il pas un impact de ce coté là ? Les ressources sont-elles remise à dispo assez rapidement après utilisations (sockets) ?

@plow personnellement ce n'est pas le backoffice qui me dérange le plus mais plutôt le frontend. Et d'ailleurs le backoffice prestashop est relativement confortable en utilisation. Évidement beaucoup moins rapide que sur un vps mais comme je suis le seul à l'utiliser ;-)

Enfin je souligne que mon expression de ce constat n'est pas un jugement négatif de Yulpa.io et que je suis conscient du travail fourni par l'équipe. On essaye de faire mieux avec ce qui existe et je sais que ce n'est pas facile.

merci à tous.

Manu

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci à tous les protagonistes de relancer le débat, je pense qu'il est nécessaire. On s'est tous pris la tête de soirées entières à optimiser nos sites et voir que les résultats ne payent pas est frustrant. Nous sommes certes une petite minorité mais nous partageons majoritairement tous les mêmes symptômes.

Je ne sais pas si c'est réellement à nous de répondre à la question de savoir pour certains sites fonctionnent bien et d'autres non.

Je sais très bien de tous les efforts que vous avez fait Yulpa pour offrir au plus grand nombre un service exemplaire. Mais concrètement qu'avons nous comme solution:

  • Changer d'hébergeur ? (Je ne suis personnellement pas pour, je suis chez vous pour vos valeurs et j'y tiens)
  • Passer sur du VPS / Dédié chez vous (pourquoi pas...)
  • Ne rien faire (c'est cette solution que j'ai choisis en dépit...)
Modifié par Alex

Partager ce message


Lien à poster
Partager sur d’autres sites

@Alex je ne suis pas sûr que l'herbe soit plus verte à coté et comme je ne suis pas joueur de poker, je déteste l'idée de "payer pour voir" 😳

Pour les vps, on en parle beaucoup mais honnêtement l'administration quotidienne d'un vps n'est pas une tâche facile, surtout dans mon cas pour une boutique ou l'aspect "financier" est primordial, donc l'aspect "sécurité" qui va avec. Et la sécurité en informatique est un emploi à plein temps. Y'a pas de chomage dans cette branche ! Une faille dans le système est c'est une société entiere qui est en danger...

Ne rien faire ? C'est à nouveau une société entiere qui est en danger car la concurrence elle n'attend pas (elle a plus de moyens). De plus l'attente des utilisateurs évolue également, et pas à la baisse. C'est pour cela que j'essaie d'optimiser mon site au maximum. Maintenant c'est vrai que quand je regarde le rapport temps investi/resultat je suis un peu déçu. Et de plus je suis maintenant à la limite des mes possibilités techniques, sauf à refaire un nouveau site ce qui est hors de question.

Il est ou le bon temps des prestashop 1.3 qui tournaient sur un céléron 😞

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 05/10/2017 à 14:26, plow a dit :

Les pings que vous citez ne rendent pas compte de l'accès administrateur (forcément hors cache) qui est ce qui me soucie.

Attention, pas forcément vrai. Dans mon agence, on a eu beaucoup de soucis avec W3 Total Cache qui a tendance à mettre tout et n'importe quoi en cache. Je pense à l'option "database caching" par exemple qui est utile sur dédié, mais une vraie plaie sur un mutu.
Attention aussi aux plugins très/trop gourmands en ressources via le BO (Borken Link, Yoast, WPML).
P3 Plugin Profiler peut vous aider à cibler les plugins qui peuvent poser problèmes.

Je vais essayer de vous retrouver l'article (en anglais) qui détailler pas mal de soucis de ce genre sur le backoffice.

De mémoire un test assez utile aussi était de passer son site sur le thème par défaut (on doit être à Seventeen là il me semble) pour voir si le thème (souvent payant... et très très mal codé) ne posait pas problème également.

Edit : j'ai mieux, quelqu'un en a fait une trad : https://www.mister-wp.com/tutos/wp-admin-lent/

Modifié par Kerweb

Partager ce message


Lien à poster
Partager sur d’autres sites

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 !

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour tout le monde.

je rejoins Plow, depuis hier ca tourne très bien !

Question : moi je n’ai rien changé sur mon « applicatif », donc j’en conclu que quand ça tourne mal le problème n’est pas de mon coté ?

Je croise les doigts pour que cet état de fonctionnement perdure !

 

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour,

Je suis désolé de constater que les ralentissements reviennent. Aujourd'hui quasi impossible de travailler en BO. Ce problème n'est pas "constant". Autant desfois une mise à jour produit va se faire en 2 clicks, autant elle ne se fera jamais car le système "hang".

Merci de prendre en compte le problème.

Cordialement,

Manu

Modifié par Lafuente

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant


×