Une problématique bien connue des moteurs de recherche : l’optimisation de leur stratégie de crawl

Voici une solution utilisée par le moteur d’Orange avec le RefreshRate 

Une des problématiques du crawl de la base d’urls d’un moteur de recherche est de sélectionner en permanence  la liste d’urls qu’il serait le plus judicieux de collecter physiquement. Pour cela il faut prendre en compte une série de paramètres comme :

– Ne pas sélectionner consécutivement plusieurs urls d’un même site dans cette liste pour éviter un « sur-crawl » qui peut charger ce site et peut-être déclencher des mesures de blacklist de la part du webmaster,

– Limiter le nombre d’urls d’une même IP pour éviter  un sur-crawl du serveur lui-même et qui peut pousser l’hébergeur à bloquer les requêtes de crawl sur ce serveur,

– Rafraichir au maximum l’ensemble des urls d’un site et donc sélectionner en priorité les urls les plus anciennement visitées de ce site,

– Collecter régulièrement les pages sans pour autant le faire de manière trop intensive par rapport à son exploitation en indexation vers le moteur,

– Eviter de crawler les urls déjà collectées et dont le contenu est « inchangé »…

Comment ne pas crawler inutilement les urls dont le contenu n’a pas changé ?

Ce critère est délicat à mettre en œuvre. Normalement, coté serveur web, un code HTTP est prévu à cet effet, le code 304 : « Not modified ». Lors de ses requêtes, le robot VoilaBot indique la date de sa dernière visite de l’url dans un champ  « If-Modified-Since: » du header HTTP  et le serveur est sensé retourner simplement un code http 304 si la page en question est inchangée depuis cette date. Cela permet de soulager la charge du serveur web et la bande passante car seul un petit header est  retourné au robot plutôt que le document complet. Quand ce cas se présente au niveau du crawl, celui-ci peut ensuite espacer les visites pour cette page.

 

Dans la pratique il se trouve hélas que moins d’une requête sur mille entre dans ce cas de figure et est capable de gérer ce code HTTP. Dans la majorité des cas, les serveurs web se contentent de  retourner un code HTTP 200 suivi du document complet, même si celui-ci n’a pas bougé d’un octet. Cela est d’autant plus vrai que pour les pages dynamiques (générées lors de la requête) il est difficile, voir impossible de mettre ce type de retour en œuvre coté serveur web.

La solution du VoilaBot, le crawler du moteur d’Orange

Une solution pour gérer cette situation a été implémentée et mise en place dans le crawl VoilaBot ! Afin de pouvoir  détecter ces codes retour  200 qui aurait dû/pu être des 304, la solution consiste à comparer le contenu de la page obtenue lors d’une collecte (ou du moins son empreinte) à celle mémorisée lors de sa collecte précédente.  On peut ainsi repérer des pages réellement statiques qui n’évoluent pas dans le temps et les « considérer » dans la base de crawl comme des pseudo-304. Evidement, le contenu a quand même été retourné cette fois-ci, mais on va pouvoir retarder sa prochaine visite. De la même façon, si le contenu de la page a changé depuis la dernière visite, on peut alors considérer cette page comme dynamique et rapprocher la date de sa prochaine visite.

Pour cela, une valeur entière associée à une page web indique un nombre de jours à attendre avant sa prochaine collecte : le refreshrate.

Une page inchangée va voir sa valeur de refreshrate augmenter, alors qu’une page qui  est régulièrement modifiée par son webmaster va voir sa valeur de refreshrate diminuer. Evidement, ces valeurs sont bornées à un minimum de quelques  jours pour éviter des surcrawl de la page elle-même, et un maximum de quelques mois  afin de conserver un contact avec celle-ci dans le cas où elle viendrait quand même à évoluer à un moment donné.

 

 

Dans la pratique, une page est crawlée pour la première fois et est planifiée pour être  visitée par défaut tous les 7 jours. Lors du deuxième crawl,  si celle-ci est différente, elle sera programmée pour être visitée après 4 jours, si à la troisième visite cette page est encore différente, elle sera visitée tous les 3 jours par la suite. Si par contre la page est statique, les prochaines visites vont être programmées successivement tous les 10, puis  13, puis 16, puis 18 jours… avec un plafonnement tous les deux mois.

Le résultat de cette mise en œuvre est probant ! Une page sur quatre est physiquement  inchangée d’un crawl à l’autre!

Après avoir pris en compte cette valeur de « refreshrate » dans la requête de sélection des urls candidates au crawl à un instant t, il se trouve qu’après une phase de mise en place, la réduction d’urls collectées se compte ainsi en centaines de millions par jour!

De plus, le fait d’utiliser des valeurs entières de nombre de jours pour le refreshrate fait que les urls candidates au crawl pour un jour J le sont à partir de minuit. La volumétrie de crawl ayant été réduite pour la capacité de la plateforme, il se trouve que le crawl est plus important entre minuit et le début de matinée, heures auxquelles les serveurs web francophones sont à priori les plus disponibles car le moins sollicités par leurs propres internautes.

Par exemple, en 2011, le profil journalier du nombre d’url collectées/secondes sur un des serveurs de crawl était le suivant:

 

Aujourd’hui, avec la prise en compte du refreshrate, il est celui-ci :

 

Les bénéfices de cette solution

L’impact direct de cette implémentation de l’algorithme de crawl est la suivante :

–          Allégement de la Bande Passante consommée coté Orange et coté sites distants (hébergeurs, webmaster,…)

–          Allègement de la charge des serveurs de crawl, ce qui libère du temps CPU et I/O pour faire d’autres traitements d’analyse, de statistique ou de maintenance.

–          Prise en compte des pages dynamiques (php) qui n’évoluent pas dans le temps.

–          Possibilité de catégorisation des pages actives et inactives

Et côté Sites, quels sont vos retours sur les stratégies de crawl des moteurs ?

 Avez-vous détecté une différence depuis la mise en place du RefreshRate par lemoteur ?

Subissez-vous souvent des surcrawls de la part des moteurs de recherche ?

Avez-vous pensé à nous contacter pour améliorer la collecte de vos sites ?

L’équipe Moteur est soucieuse de trouver toujours de nouvelles améliorations sur sa façon de collecter, d’extraire du web les sites de qualité  et pour cela rien de mieux que d’échanger avec les webmasters. N’hésitez pas à venir discuter avec nous sur ces sujets  sur ce blog.

CyberChimps