Comment ATS met en œuvre des stratégies de mise en cache pour augmenter le débit des services dynamiques

Tout d'abord, jetons un coup d'œil au graphique de trafic immédiatement après l'ajustement de la politique :

Afin d'améliorer l'expérience utilisateur, d'augmenter le taux d'amplification du cache et en même temps d'éviter les rapports clients, cela peut Il faut dire que nous prenons beaucoup de peine lors de la mise en cache. Les fichiers volumineux, les petits fichiers sont séparés et le contenu dynamique et le contenu statique sont séparés dans de petits fichiers. Fondamentalement, tout ce qui peut être enregistré est enregistré. Seul le contenu dynamique n'a pas été démarré. Selon la stratégie précédente, le contenu dynamique est directement proxy, avec une entrée et une sortie 1:1, mais certains plans de jeu ne s'arrêtent tout simplement pas et insistent pour atteindre un certain rapport de grossissement. S'il n'est pas cassé, utilisons le couteau dans le. contenu dynamique.

Avant de passer sous le bistouri, j'ai d'abord fait une analyse et fait de nombreux tests sur le contenu dynamique pouvant être stocké et la stratégie de mise en cache ATS, et j'en ai beaucoup bénéficié. La stratégie de mise en cache actuelle d'ATS est entièrement conforme au protocole HTTP et adopte la méthode de mise en cache la plus conservatrice, c'est-à-dire que seules les informations avec un en-tête de cache de cycle de vie clair ne sont pas stockées. configuration correspondante en ats Les paramètres ne seront pas écrits. Afin de garantir la qualité, nous ignorons directement le contenu dynamique avec cookies et autorisation car le risque est trop élevé. Les catégories restantes peuvent être essayées :

1. Images d'URL dynamiques et autres contenus avec des en-têtes de cycle de vie clairs (nous supposons que ; les informations d'en-tête du site Web sont dignes de confiance)

2. Images d'URL statiques, images d'URL dynamiques, etc. sans en-têtes de cycle de vie d'en-tête clairs, y compris des images sans aucune information ou uniquement des en-têtes et autres informations modifiés en dernier lieu.

Pour la catégorie 1, c'est facile à gérer. ats a les paramètres correspondants, ouvrez-le simplement :

proxy.config.http.cache.cache_urls_that_look_dynamic INT 1

Pour la catégorie 2, c'est un travail technique à gérer en premier. dans l'ensemble, les conditions nécessaires pour les informations d'en-tête en ligne sont :

proxy.config.http.cache.required_headersINT 2

Ce n'est qu'en assouplissant les restrictions à ce sujet que la deuxième catégorie peut être incluse, donc la définir sur 0 est la première nécessité est de savoir comment pour assurer un service normal après sa configuration. Par exemple, le code de vérification n'a aucune information d'en-tête lorsqu'il est configuré. Une stratégie conservatrice fournira certainement un service normal, mais si vous le laissez partir, cela causera certainement des problèmes. Après analyse, ats utilise le temps de cache maximum et minimum pour garantir le temps de cache du contenu sans informations d'en-tête. Les deux paramètres de temps sont les suivants :

proxy.config.http.cache.heuristic_min_lifetime INT 3600

proxy.config.http. . cache.heuristic_max_lifetime INT 864000

Pour information avec uniquement le dernier en-tête modifié, il est calculé via le facteur de vieillissement. Les paramètres du facteur de vieillissement sont les suivants :

proxy.config.http.cache.heuristic_lm_factor-v 0.1

. J'ai donc eu une idée, le contenu Pass-through après l'arrivée, mais avant chaque crachat, demandez à ATS d'envoyer des informations d'en-tête IMS à la station d'origine pour demander s'il y a un changement. Puisque ces informations d'en-tête ne sont qu'une requête, il n'occupera pas beaucoup de trafic. S'il n'y a pas de changement, TCP_REFRESH_HIT sera craché vers l'utilisateur, bien qu'il soit renvoyé à l'origine, mais le contenu est toujours craché du cache. est craché à l'utilisateur. L'utilisateur obtiendra également le dernier contenu, ce qui augmentera de manière invisible le flux de crachat.

Mais comment régler les paramètres ? Il m'est soudain venu à l'esprit que je pouvais mettre tous les paramètres ci-dessus à 0, ce qui a théoriquement atteint mon objectif. Après l'avoir enregistré pour la première fois, j'ai commencé à demander à l'en-tête IMS de revenir à la source à partir de la deuxième fois et j'ai immédiatement trouvé un test. environnement de test. C'était comme prévu. De même, lorsque j'étais excité, j'ai immédiatement mis à jour la stratégie en ligne et je l'ai surveillée pendant une heure via l'outil de graphique de trafic. Le retour global à l'origine a également été réduit, mais quelque chose d'étrange s'est également produit. tsar de voir que le retour à l'origine à certains moments était toujours le même. C'est presque comme vomir, et après l'avoir analysé avec traffic_logstats -s, j'ai trouvé qu'il y avait beaucoup de ERR_CLIENT_ABORT, ce qui est vraiment terrible. le client a activement déconnecté la connexion avant d'avoir fini de recevoir les données après la connexion. Si c'est moins, c'est normal, si c'est plus, ce sera un problème Oui, j'ai trouvé une image de 1 M avec un âge maximum pour les tests que j'ai purgés. d'abord, puis j'ai bouclé la connexion et je l'ai déconnectée immédiatement, créant ce journal d'erreurs. La deuxième fois que j'ai visité, il s'est avéré qu'il s'agissait de TCP_HIT. J'ai téléchargé l'image locale et je l'ai ouverte normalement, il s'avère que ATS continuera. à télécharger dans le cache face à ce problème. La qualité de ces noms de domaine étant médiocre, le trafic de retour est parfois très élevé. J'ai continué à chercher des informations sur Google et j'ai trouvé cet article :

proxy.config. http.background_fill_completed_thresholdFLOAT 0.5

La valeur par défaut est définie sur 0. Ce paramètre signifie que le client se déconnecte soudainement lorsque le téléchargement atteint un certain pourcentage, sinon il sera déconnecté. Non Après y avoir réfléchi davantage, je l'ai défini. à 0,5, j'ai fait un test, puis je l'ai mis à jour immédiatement. Le trafic est devenu stable et le débit a également augmenté.

Finalement, c'est un petit succès. Les paramètres en ligne ne sont pas si stables. Il faut encore ajuster le test en fonction de la situation commerciale à l'avenir, mais cela fait aussi partie du plaisir.

Tous les ajustements sont un équilibre. Les ajustements actuels : 1. Augmentation des E/S de lecture et d'écriture du disque 2. Augmentation de la charge du processeur.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!