Quand un cache de proxy partagé aide un crawler
Évaluez les ressources répétées, la fraîcheur et les requêtes réelles du crawler avant d'attendre d'un cache de proxy direct partagé un meilleur débit.
Supposons que plusieurs travailleurs dans un navigateur ouvrent différentes pages d'un même site. Ces pages référencent la même feuille de style, le même logo et le même paquet de scripts. Un cache direct partagé peut rendre la première requête utile aux travailleurs suivants lorsque les réponses sont réutilisables.
Changez maintenant la charge: chaque travailleur ne télécharge qu'un document HTML et ne charge jamais ses ressources liées. La feuille de style commune est toujours présente dans le balisage, mais aucun travailleur ne la demande. Elle n'apporte rien au taux de succès du cache du proxy.
Partez des requêtes que votre crawler effectue réellement
Un navigateur qui affiche une page et un client HTTP qui récupère sa source créent des ensembles de requêtes différents. Examinez ces ensembles avant de choisir une conception de cache.
| Charge de travail | Potentiel de réutilisation partagée |
|---|---|
| Les travailleurs récupèrent à plusieurs reprises les mêmes ressources publiques | Utile lorsque les règles de fraîcheur et de clé de cache le permettent |
| Chaque requête a une URL ou une variante de réponse unique | Peu de recouvrement à réutiliser |
| Une réponse doit être revalidée avant réutilisation | Peut économiser des octets de réponse tout en nécessitant un aller vers l'amont |
| Les travailleurs satisfont déjà des requêtes depuis leur cache local | Ces requêtes peuvent ne jamais atteindre le proxy partagé |
La seule égalité d'URL ne suffit pas. La politique de fraîcheur de la réponse et les champs nommés par Vary peuvent distinguer des représentations. Un contenu privé, non stockable ou authentifié relève des règles applicables aux caches partagés; il ne faut pas le forcer dans un seul résultat public uniquement pour augmenter le nombre de succès.
Pour le trafic HTTPS CONNECT ordinaire, le proxy direct transporte un tunnel chiffré et ne contient aucun objet HTTP à mettre en cache. Un déploiement avec inspection TLS a un comportement de confiance et de traitement différent. Précisez le mode réel lorsque vous évaluez la disponibilité de la mise en cache d'objets.
Un succès de cache peut éviter une récupération en amont, tandis qu'un échec paie encore le travail de l'intermédiaire. Comparez les octets utiles terminés, le trafic amont et la latence pour la charge prévue. Le nombre de threads décrit la concurrence; il ne décrit pas la quantité de contenu réutilisable que ces threads partagent.