Maintenir à jour l’index Solr d’un site Drupal
Optimiser la configuration de cron pour le moteur de recherche.
Pour certains sites Web, il est essentiel que
l’index de recherche soit mis à jour très fréquemment. C’est le cas de sites où
la fréquence des ajouts ou modifications aux contenus est très grande; à la
limite, avec une fréquence d’indexation trop basse, le système pourrait alors
ne jamais venir à bout de la liste de contenus à indexer! Certains sites, par
ailleurs, dépendent de requêtes de recherche pour alimenter directement une
interface de navigation, rendant particulièrement désirable la présentation de
données aussi actuelles que possibles.
Nous avons été confrontés à ces enjeux récemment dans le projet d’une communauté en ligne. D’une part les participants sont invités à importer de grandes quantités de données et d’images, ce qu’ils peuvent faire en quelques clics via des fonctions de transfert massif de données et de fichiers, tandis que, d’autre part, l’interface du site est presque entièrement axée sur une navigation par facettes alimentée et filtrée par Solr où, en fin de compte, la plupart des contenus sont invisibles s’ils ne sont pas indexés dans Solr. Dans ce projet particulier, l’un des souhaits est que des milliers contenus nouvellement transférés par un membre deviennent accessibles à la communauté dans un délai de quelques minutes plutôt qu’après quelques heures.
Le présent article décrit la manière dont nous avons résolu ce type de problème sur un site Drupal utilisant le module Apache Solr.
Lancer le cron plus souvent
Une approche simpliste consiste à augmenter le nombre d’éléments indexés par exécution de la tâche cron, puis à exécuter ladite tâche plus fréquemment; on déclenche alors une indexation plus fréquente d’un plus grand nombre d’éléments. Sur une bonne machine, Solr peut aisément indexer des milliers de contenus en quelques secondes, ce qui permet d’envisager une actualisation de l’index plusieurs fois par heure, voire à toutes les minutes. Comme Solr démarre une nouvelle « vue » sur l’index (un « IndexSearcher ») après chaque soumission (ou « commit ») de l’index, on doit seulement prendre soin de ne pas imposer une fréquence telle que Solr n’aurait pas le temps de lancer sa nouvelle vue avant de commencer une nouvelle ronde d’indexation.
Mais il y a un hic : L’exécution du script cron.php d’un site Drupal implique un grand nombre de tâches autres que l’indexation. On peut penser par exemple au nettoyage des journaux et des sessions, à l’agrégation de contenus, à l’envoi de courriels, à la création de copies de sécurité, à la notification ou synchronisation d’autres sites ou services, le tout étant fonction des modules installés et de leurs configurations. Certaines de ces tâches peuvent être relativement lourdes. À moins d’avoir une idée claire de ce qui se passe lorsque cron.php est lancé, il peut être imprudent de le faire plusieurs fois par heure. Je ne recommande certainement pas l’invocation de cron.php à toutes les minutes.
Lancer le cron plus intelligemment
Une approche plus raffinée et néanmoins très simple à déployer mise sur le module Elysia Cron. Ce module fournit un contrôle plus granulaire sur les tâches à appliquer au lancement de cron.php. Il offre, pour chaque module du site ayant besoin d’exécuter des tâches régulières (i.e. implémentant hook_cron), la possibilité de choisir la fréquence d’exécution applicable à ce module. Il montre aussi le temps d’exécution afférent à chaque module, ce qui peut être instructif et risque même, à l’occasion, de révéler, on le verra, quelques surprises.
L’utilité de Elysia Cron va bien au-delà de la configuration de la fréquence d’indexation, mais je vais me concentrer ici sur le problème qui nous concerne. L’objectif est d’actualiser l’index Solr environ aux deux minutes, tandis que les autres tâches régulières du site seront exécutées une fois l’heure. Après avoir installé Elysia Cron suivant la procédure habituelle d’installation d’un module, puis accordé la permission administer elysia_cron à l’administrateur, on visite la page Administrer > Construction du site > Cron settings pour rejoindre le cœur des réglages du module. La zone Single job settings montre la liste des implémentations de hook_cron. Il s’agit d’entrer un identifiant de notre choix, disons « indexation », dans le champ Context des lignes apachesolr_cron et apachesolr_search_cron, puis d’enregistrer les changements. Ensuite, dans la zone Contexts settings de la même page, on spécifie « * * * * * » sous Default schedule rule pour notre contexte « indexation », laissant vide ce même champ pour la ligne « default ».
Après avoir enregistré ces changements (voir l’image ci-jointe pour un aperçu), on modifie ensuite la procédure habituelle de configuration du cron, en remplaçant la fréquence d’exécution de cron.php de « 45 * * * * » par « * * * * * » (pour exécution à chaque minute). Ainsi le tour est joué : Elysia Cron sera invoqué à chaque minute et contrôlera l’exécution des tâches pertinentes en fonction de la fréquence associée à leur contexte.
Parce que nous avons créé deux contextes et que Elysia Cron ne les considère qu’en alternance, l’indexation sera finalement exécuté aux deux minutes environ. Il n’est pas recommandé de créer un grand nombre de contextes puisque les fréquences d’exécution effectives risquent alors de s’éloigner de celles souhaitées.
Désactiver l’indexation par défaut de Drupal
Le module Apache Solr dépend de fonctions de base fournies par le module search du noyau Drupal. Ainsi, si Apache Solr est activé sur votre site, search le sera également. Une conséquence importante de cette dépendance est que search effectuera aussi sa propre indexation, et ce même si vous avez activé l’option Make Apache Solr Search the default! Cette indexation par search est alors redondante et, surtout, beaucoup plus lente que l’indexation de Solr. Voilà justement le type de surprise que Elysia Cron peut facilement révéler à travers sa fonction de statistiques.
Si vous souhaitez utiliser search comme moteur de rechange en cas de défaillance de Solr, vous devrez absolument considérer une politique d’indexation moins agressive que ce qui est possible avec Solr. L’indexation du module search est beaucoup plus lente que celle de Solr. Si vous choisissez de dépendre uniquement de Solr, ce qui m’apparaît généralement idéal, un truc pour alors épargner le serveur consiste à désigner Solr comme l’unique moteur du site, puis à désactiver la tâche d’indexation de search en cochant sa case Désactivé dans les paramètres de Elysia Cron.
Des alternatives
Au moment d’écrire ces lignes, la version 2 du module SuperCron, dont les objectifs sont très semblables à ceux de Elysia Cron, ne s’avérait pas très stable. Cependant il se pourrait qu’elle devienne une alternative viable dans le futur.
Par ailleurs, on pourrait envisager d’autres stratégies d’indexation avec Solr, comme la possibilité de passer par la commande drush, auquel le module Apache Solr adjoint des options additionnelles (drush solr-reindex). Ceci pourrait nous dispenser complètement d’un module comme Elysia Cron, bien que ce dernier reste intéressant au-delà de la seule question de l’indexation.
Enfin, puisqu’il y a toujours plusieurs façons d’arriver à nos fins avec Drupal, il faut noter que search peut également être neutralisé en réglant à zéro son option Nombre d’éléments à indexer par tâche cron. Si vous utilisez Solr comme unique moteur sur votre site et que vous préférez ne pas installer un module tiers pour gérer les tâches cron, il s’agit d’un réglage fort souhaitable.
Conclusion
Elysia Cron est un petit module intéressant à découvrir et facile à déployer qui permet de mieux contrôler la sélection et la fréquence des tâches régulières à faire tourner par le cron d’un site Drupal. Avec ce module, on peut aisément augmenter la fréquence d’indexation, tout en conservant une fréquence d’exécution raisonnable pour les autres tâches régulières. En outre, on peut passer par Elysia Cron pour neutraliser les tâches indésirables, telles que l’indexation faite par le module search du noyau Drupal, inutile lorsqu’on a substitué le module search par un autre moteur de recherche.
Commentaires