Hébergement Web-old - Chargement très lent
... / Chargement très lent
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Frage

Chargement très lent

Von
kingkurt
Erstellungsdatum 2017-01-06 10:54:18 (edited on 2024-09-04 11:03:36) in Hébergement Web-old

Je constate depuis hier que le chargement des mes sites sont sporadiquement très lent.
A certaines moments même des times out pour accéder au back-office pour ceux qui sont en WP
Y a il un problème des serveurs OVH ?
Herbergement pro 2014
CDN
Cluster 14
Filer 151

Je regardé dans le manager 2 screenshots qui me paraissent bizarre mais je n'ai pas d'explication .
Qq une idée ?imageimage


20 Antworten ( Latest reply on 2018-03-31 16:30:23 Von
kingkurt
)

Quand ça m'arrive, premier réflexe consultez les travaux chez OVH : http://travaux.ovh.net/
Je suis sur le cluster 12, je dois avoir un vieux serveur car il a souvent été en réparation et depuis quelques mois, ça déraille un peu trop souvent à mon goût.

Url?

Quelle environnement ? Stable ou legacy ?
Quelle version de php ?

app.engine=php
app.engine.version=7.1
http.firewall=none
environment=production
container.image=stable

Pour l'URL
J'en ai 4
Et c'est surtout les backoffices qui prennent un temps enorme (sporadiquement)
p.ex
http://paris.1scout.com/wp-admin/scout.com/wp-admin/

Le test suivant indique déjà que la mise en cache des ressources statiques est relativement mauvaise (15 min)

https://gtmetrix.com/reports/paris.events-scout.com/XQsRgXP8

Peut être que l'augmenter limitera le nombre de requêtes traitées par le serveur et lui permettra d'afficher le panneau admin..

Merci Buddy
Mais GTmetrix donne très souvent des mauvais résultat car ils sont au Canada
Pour le site en question c'est le seul que j'ai qui n'est pas en CDN (pour le moment)
J'ai changé un peu la cofig. du cache
Et sur pingdom ça donne
https://tools.pingdom.com/#!/eA9qJW/http://paris.events-scout.com
Load time
1.98 s
De toute façon ça n'explique pas les graphiques des temps de réponse subitement 5 fois plus elevés depuis lundi


Mais GTmetrix donne très souvent des mauvais résultat car ils sont au Canada


Oui et non. Sur les temps de chargement oui. Sur les analyses non.

Quand ils disent que les images ne sont pas en cache (ou que la mise en cache est inférieure à 30 min) ça ne dépend pas de la location.. ( Leverage browser caching par exemple )
Sur un site bien il est tout à fait possible d'avoir plus de 75...

Il faut augmenter la mise en cache.

En tout cas comme j'ai dit j'ai encore modifié les réglages pour ce site avec le plugin fastes Cache - est j'ai mis toutes les options possibles (pour la version gratuit)

Je suis tombé sur le problème car pour tous mes sites en Wordpress j'ai constaté depuis hier que en allant sur la page login admin il y a des lenteurs voir des times out !
Sinon pour les pages en front de tous mes sites WP ou pas c'est difficile à dire !
Mais comment expliquer les "Temps moyen de réponse" des graphiques dans le manager (static & dynamiques) ?

N.B. pour le moment il semble impossible d'accéder aux logs via le manager OVH

En fait l'hébergement peut gérer par exemple 100 requêtes par seconde.. (chiffre au hasard)

Si les images sont mises en cache, ça fait autant de requêtes en moins à (re) traiter.
Donc du coup l hébergement a plus de ressources pour traiter les pages php.

Également, https://paris.1scout.comscout.com est accessible en https.
Autant le forcer..
Panneau admin de wordpress puis réglages puis mettre https dans l'URL de wordpress et du site. + activer le hsts'

Bon la mise en cache des images sert seulement à quelque chose si les visiteurs reviennent souvent.
Et spécialement pour ce site là il y a pour le moment très peu des visites (30-40 par jour)
(mon site principal non-WP en a 1000 à 2000 par jour)
L'autre problème avec la mise en cache est si ont modifie les images sans changer le nom les anciennes versions ressent en cache.


Également, https://paris.1scout.comscout.com est accessible en https.
Autant le forcer..

Oui je sais c'est le seul site que j'ai laissé en http. Si je passe en https il faut que je vérifies tous les liens directs vers les images et pages (il y a des dizaines des milliers)

Par contre je n'ai toujours pas trouvé d'explication pour le "Temps moyen de réponse" depuis lundi. Dans les logs (qui ont des milliers de lignes pour le web) je ne trouve rien d'anormal au premier vu


L'autre problème avec la mise en cache est si ont modifie les images sans changer le nom les anciennes versions ressent en cache.


ça arrive souvent sur le site ?

Sinon, actuellement le site est accessible avec et sans https, est-ce que la "saturation" depuis lundi ne serait pas dû à un robot (Google Bot par exemple) qui indexe en double chaque page (Avec et sans https).

C'est mon avis personnel, mais d'ici maximum 2 mois, le site devrait être en full HTTPS dans google... (il y a déjà des pages indexées en https://) donc à mon avis, c'est déjà quasiment trop tard ...

Sinon, un test rapide via https://www.jitbit.com/sslcheck/ indique que le seul "problème " actuellement est le lien

`http://paris.1scout.com/wp-content/uploads/shadowbox-js/src/shadowbox.css?ver=3.0.3` scout.com/wp-content/uploads/shadowbox-js/src/shadowbox.css?ver=3.0.3`
qui a mon avis sera réglé rapidement via le paramétrage dans le panneau admin wordpress.

Merci Buddy pour tes réponses.
Depuis cette nuit tout semble être revenue à la normal, tant le temps d'accès aux backoffices WP tant les graphiques dans le manager OVH

Sans que j'aie changé quelque chose !
En regardant les graphes sur 1 an je me suis rendu compte qu'il y a sporadiquement des pics

sans raison. Alors je suppose que c'est plutôt dû à une surcharge des servers d'OVH ?


Sinon, actuellement le site est accessible avec et sans https, est-ce que la "saturation" depuis lundi ne serait pas dû à un robot (Google Bot par exemple) qui indexe en double chaque page (Avec et sans https).


Effectivement il semble que Google a indexé certaines pages en https. Mais les crawlers de Google ne font pas plomber les sites à mon avis normalement. Selon mon Google search console ils explorent entre 92 et 2400 pages pas jour sur ce site. Et les pics d'exploration ne correspondent absolument pas aux pics des graph de l'hébergement.

Bon pour passer ce site en https je vais voir à un moment calme


Mais les crawlers de Google ne font pas plomber les sites à mon avis normalement. Selon mon Google search console ils explorent entre 92 et 2400 pages pas jour sur ce site.


2400 pages ça commence à faire beaucoup si le thème est lourd.. Il faut comparer aussi au nombre de visite par jour..


Selon mon Google search console ils explorent entre 92 et 2400 pages pas jour sur ce site.

Comment vois-tu cela ?
Combien de page le site concerné a-t-il de pages ?


Comment vois-tu cela ?



-> Exploration -> Statistiques sur l'Exploration


2400 pages ça commence à faire beaucoup si le thème est lourd..


Ca fait au grand max 100 par heure (si c'est bien reparti) avec un temps chargement de 0,2 à 2 sec normalement n'importe que hébergement doit tenir la route non ?

Merci @kingkurt.

Mais mes logs de 1xxx.googlebot.comxxx.googlebot.com sont de **_la moitié ou du tiers_** de ce que je vois sur -> Exploration -> Statistiques sur l'Exploration.


avec un temps chargement de 0,2 à 2 sec


actuellement, il me semble que les temps sont quand même nettement plus long.

ensuite, il n'y a pas que Google comme Robots (il y a aussi d'autres moteurs de recherche et des robots malveillants/peu utiles) et éventuellement des visiteurs aussi ^^

http://paris.1scout.com/robots.txtscout.com/robots.txt
typiquement, je crois que AhrefsBot ne sert à rien ...
idem pour la majorité des robots qui indexe les images, javascript, css et etc ...

Bref tout ceci est autant de requêtes à traiter..
Normalement avec la mise en cache des pages php et des images, ça devrait marcher.


ensuite, il n'y a pas que Google comme Robots (il y a aussi d'autres moteurs de recherche et des robots malveillants/peu utiles)



C'est vrai mais de bloquer ceux qui sont les plus inutiles me semble le plus difficile !

Normalement avec la mise en cache des pages php et des images, ça devrait marcher.


Presque toutes mes pages php sont déjà en cache. Et mettre en cache (navigateur) les images sert seulement si tu as beaucoup des visiteurs revient souvent sur les pages. Et les robots je ne pense pas qu'ils ont un sort de cache navigateur ?

Comme dit plus haut pour mon hébergement tout est revenu à la normal depuis 3 h ce matin (selon les graphiques OVH). Et là ça n'a rien a avoir avec les pages et caches ... non


C'est vrai mais de bloquer ceux qui sont les plus inutiles me semble le plus difficile !

Il faudrait voir les logs du site. Si un robots fait des centaines de requêtes ça se voit vite.

les images sert seulement si tu as beaucoup des visiteurs revient souvent sur les pages. Et les robots je ne pense pas qu'ils ont un sort de cache navigateur ?
Les robots non, ils ne les chargent pas forcément d'ailleurs.
Aucun visiteur sur le site ne revient par exemple tous les jours ? 2 ou 3 jours ? même si il y a 15 visiteurs qui reviennent tous les jours, vu qu'il y a environ 120 requêtes sur le site, ça fait environ 1500 requêtes évités. Si c'est en heure creuse, ça sera transparent, par contre, si c'est à l'heure de pointe c'est un bon gain.


Comme dit plus haut pour mon hébergement tout est revenu à la normal depuis 3 h ce matin (selon les graphiques OVH). Et là ça n'a rien a avoir avec les pages et caches ... non


Pourquoi ça n'aurait rien à voir avec les pages ? Combien y avait il de robots à cette heure ci ?
Les logs ont ils été analysés ?

Je ne dis pas que OVH n'a pas de lenteurs, mais la majorité des personnes (95 % ?) qui viennent se plaindre ici ont leur site qui rament moins simplement en
1) basculant sur une version php récente (donc plus rapide à exécuter les scripts)
2) mettant en cache les pages générées et les images/css/js dans les navigateurs.

Woocommerce n'est pas réputé pour sa légèreté...


Les logs ont ils été analysés ?



A propos des logs:
J'ai souvent des requêtes pour un fichier GET /crossdomain.xml qui finissent logiquement en 404 car il n'y a aucun fichier crossdomain.xml sur mon hébergement
exemple
`76.10.17.120 1blog.frankreich-trip.comblog.frankreich-trip.com - [21/Feb/2018:00:26:22 +0100] "GET /crossdomain.xml HTTP/1.1" 404`
Une idée qu'est-ce que c'est ? Et pourquoi ces requêtes à répétition (parfois 600 par jour) ?