Le vernissage attend le chargement complet de la page avant d'envoyer la réponse au navigateur

Question

J'ai installé le vernis pour m'asseoir devant un serveur Tomcat. Ce que j'ai remarqué, c'est que Varnish semble attendre que la page complète soit chargée (tous les css, js, etc) avant d'envoyer une réponse au navigateur.

Cela entraîne un décalage énorme avant que l'utilisateur ne voit quoi que ce soit. Si je contourne Vernis et vais directement sur le site, il répond immédiatement.

Bien que le temps de chargement total de la page puisse être similaire, la perception est que le site est lent.

Est-ce que quelqu'un a fait face à cela?

Answer 1

Avec la page complète à charger (tous les css, js, etc) vous voulez dire seulement les ressources js et css intégrées, ai-je raison? Varnish tamponnera (et stockera si tout va bien) une réponse dans son ensemble, avant de l'envoyer au client. Si votre serveur envoie une réponse de manière incrémentielle (par exemple, en bloc), une page non mise en cache peut apparaître plus lente car elle est uniquement livrée par vernis après que le back-end a envoyé sa dernière pièce.

En cas de problème, modifiez le design technique de votre application. Assurez-vous que la plupart des requêtes peuvent être traitées à partir du cache (ces pages seront très rapides) et extériorisez les ressources CSS de cs & (le cache du navigateur évite de faire des requêtes du tout). Si une petite partie seulement de votre page est lente et mal mise en cache, chargez-la de manière asynchrone (par exemple, Ajax). Il y a aussi le concept du rendu incrémental (un navigateur rend les pages à mesure que plus de ressources deviennent disponibles), mais je ne vois pas comment Varnish pourrait changer ce comportement.

Answer 2

À moins que vous n'ayez incorporé JS et CSS dans votre code HTML, le comportement que vous décrivez est techniquement impossible. Votre navigateur devra recevoir et analyser le code HTML pour extraire les balises <script> et <link> et envoyer des requêtes HTTP séparées; Même s'ils arrivent au même serveur Varnish, ils n'auront aucune idée qu'ils font partie de la même "page". Essayez de changer le code HTML pour charger les données statiques (JS, CSS et images) à partir d'un autre nom d'hôte qui ne va pas à Varnish; Cela devrait faciliter le débogage. Vous pouvez obtenir le même résultat en utilisant un client HTTP en ligne de commande, par ex. curl. Si vous constatez toujours la même performance lente dans ce scénario, consultez les journaux de vernis, il vous donnera probablement quelques idées pour plus de choses à vérifier. N'hésitez pas à ajouter cela comme commentaire, de cette façon, nous serons en mesure de mieux vous aider.

Answer 3

Je pense que vous étiez confus par le tampon de réponse de vernis. Disons que le plus rapide que votre backend peut répondre avec une page de 100k pour une requête donnée est de 10 secondes, envoyant 10k chaque seconde. Sans vernis dans votre pile, la connexion du client obtient un tunnel directement à l'arrière, et le navigateur commence à recevoir des données en 1 seconde (le premier 10k, et commence à analyser, rendre, suivre <link> étiquettes, etc). Avec le vernis dans votre pile, il attend que l'extrémité arrière envoie la page entière avant d'envoyer le premier octet au client. Donc, le client doit attendre 10 secondes avant de pouvoir commencer à rendre la page, en suivant les <link> étiquettes, etc. Croyez-le ou non, c'est une bonne chose pour deux raisons principales. Premièrement, si cette réponse est cacheable, le client suivant n'aura pas à attendre 10 secondes pour que le back-end génère la réponse, le vernis le servira assez rapidement (ms, pas s). Si votre taux de réussite est élevé, ce que vous devez optimiser, le coût initial d'avoir à attendre le premier octet de la réponse rapporte beaucoup de dividendes dans les futurs hits de cache.Deux, disons qu'un téléphone portable sur un signal de cellule ponctuelle demande la même page 100k, mais il ne peut pas télécharger la page aussi vite que le backend peut la générer, il lui faut une minute entière pour recevoir la page 100k. Avec le vernis en place, apache ne doit pas perdre une connexion et enfiler pendant une minute entière (la plupart du temps inactif, attention à vous) pendant qu'il transmet lentement les données au client. Il envoie les données aussi rapidement que possible pour vernir, puis passe à la requête suivante tandis que vernis envoie les données lentement au client.

Pour les demandes qui ne sont pas susceptibles d'être mises en cache, vous pouvez configurer le vernissage via la VCL, si vous le souhaitez, au return (pipe), ce qui n'entraînera pas de mise en mémoire tampon des réponses. Il enverra les données directement de votre back-end au client dès qu'il le reçoit. Mais dans le tube default.vcl n'est pas utilisé.