Comment réduire le temps "d'attente" du serveur?
J'essaie d'optimiser la vitesse de mon site et j'utilise le grand outil à pingdom.com . À l'heure actuelle, plus de 50% du temps nécessaire pour charger la page est le temps "d'attente", comme indiqué dans la capture d'écran ci-dessous. Que puis-je faire pour réduire cela? De plus, à quel point ce chiffre est-il typique? y a-t-il des repères à ce sujet? Merci!
EDIT: Ok .. permettez-moi de clarifier certaines choses. Il n'y a aucun script côté serveur ni appel de base de données en cours. Juste HTML, CSS, JS et images. J'ai déjà fait des choses comme Push js à la fin de la balise body pour obtenir des téléchargements parallèles. Je suis conscient que le main.html et les templates.html s'ajoutent au temps d'attente global en se faisant de manière synchrone après les téléchargements de js.js, ce n'est pas le problème. Je suis juste surpris de voir combien de temps "d'attente" il y a pour chaque demande. La distance du serveur affecte-t-elle cela? qu'en est-il d'être sur un serveur partagé, cela affecte-t-il le temps d'attente? Y a-t-il des fruits bas pour remédier à ces problèmes?
La raison la plus courante à cela dans le cas d'Apache est l'utilisation de la recherche d'inversion DNS. Cela signifie que le serveur essaie de comprendre le nom de votre machine à chaque fois que vous faites une demande. Cela peut prendre plusieurs secondes, et cela explique pourquoi vous avez un long temps d'attente et ensuite une charge très rapide, car il ne s'agit pas de bande passante.
La solution évidente pour cela est de désactiver hostnamelookup dans /etc/httpd/conf/httpd.conf
HostnameLookups Off
Cependant ... ce n'est généralement pas suffisant. Le fait est que dans de nombreux cas, Apache effectue toujours une recherche d'inversion même lorsque vous avez désactivé la recherche de nom d'hôte, vous devez donc examiner attentivement chaque ligne de votre configuration Apache. En particulier, l'une des raisons les plus courantes de cela est LOGS. Par défaut sur de nombreuses installations Red Hat - centos, le format de journal inclut% h qui signifie "hostname" et nécessite Apache pour effectuer une recherche inversée. Vous pouvez le voir ici:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
Vous devez modifier ces% h pour% a pour résoudre ce problème.
Si vous avez plusieurs demandes de serveur sur lesquelles la page attend, vous pouvez vous assurer que ces demandes de serveur sont envoyées de manière asynchrone en parallèle afin de les sérialiser.
Le moyen le plus lent de récupérer plusieurs demandes consiste à envoyer une demande, à attendre sa réponse, à envoyer la demande suivante, à attendre sa réponse, etc. . Cela réduit le temps d'attente total au temps d'attente le plus long pour une seule demande plutôt que le temps d'attente cumulé de toutes les demandes.
Si vous ne faites qu'une seule demande, alors tout ce que vous pouvez faire côté client est de vous assurer que la demande est envoyée au serveur le plus tôt possible dans la séquence de chargement de la page afin que les autres parties de la page puissent faire leurs affaires pendant le traitement de la demande, ce qui permet de démarrer la demande initiale plus tôt (et donc de terminer plus tôt).
Le temps d'attente, également connu sous le nom de temps jusqu'au premier octet est le temps qu'il faut au serveur pour envoyer le premier octet à partir du moment où la connexion est établie. Si c'est élevé, cela signifie que votre serveur doit faire beaucoup de travail pour rendre la page avant de l'envoyer. Nous avons besoin de plus d'informations sur ce que fait votre site pour afficher la page.
Le TTFB est directement influencé par la distance "physique" entre le navigateur et le serveur. Le proxy CDN est le meilleur moyen de raccourcir cette distance. Ceci, associé à des capacités de mise en cache natives, aidera à fournir une réponse plus rapide en chargeant l'objet mis en cache à partir de l'emplacement POP (point de placement) le plus proche.
L'effet dépendra de la géolocalisation de l'utilisateur et de la propagation du CDN. Pourtant, vous pouvez vous attendre à amélioration significative , 50% -70% ou plus.
Par expérience, j'ai vu des cas dans lesquels 90% du contenu était mis en cache et livré directement à partir d'un proxy placé sur un autre continent, de l'autre côté du globe.