Si la recherche de votre site Drupal semble lente, retourne des résultats non pertinents ou peine à supporter les pics de trafic, vous n'êtes pas seul. Solr est puissant, mais pour qu'il performe bien avec Drupal, il faut optimiser les deux systèmes ensemble plutôt que de les traiter séparément.

Introduction à la performance de recherche Solr dans Drupal

Ce guide couvre des techniques pratiques pour améliorer la performance de recherche Solr dans les projets Drupal 10 et 11. Vous apprendrez comment affiner la conception de votre schéma, configurer les gestionnaires de requêtes pour une meilleure pertinence, mettre en place une mise en cache appropriée et surveiller votre infrastructure de recherche en production. Ces approches proviennent d'implémentations réelles où les temps de réponse de recherche et la qualité des résultats posaient des problèmes mesurables.

La pile technologique standard actuelle—Search API Solr 4.3.x avec Solr 8 ou 9—alimente environ 45 000 sites Drupal. Le module supporte activement Drupal 10 et 11, avec des mises à jour de sécurité qui se poursuivront jusqu'en 2025. Cela vous donne une base solide sur laquelle bâtir.

Prérequis

Avant d'implémenter ces améliorations, assurez-vous d'avoir :

Drupal 10.2 ou Drupal 11 installé et fonctionnel
Le module Search API (8.x-1.x) configuré
Le module Search API Solr (4.3.x) installé
Solr 8.x ou 9.x en fonctionnement (local, conteneurisé ou service géré)
Un accès administrateur aux configurations Drupal et Solr
Une familiarité de base avec l'interface d'administration de Solr et ses fichiers de configuration

Vous devriez également avoir un index de recherche existant qui fonctionne mais dont la performance est insuffisante. Ces techniques présument que vous avez déjà vérifié la connectivité de base entre Drupal et Solr.

Étape 1 : Auditer et affiner la conception de votre schéma

Les gains de performance les plus importants proviennent généralement des modifications de schéma, pas des mises à niveau d'infrastructure. Commencez par examiner ce que vous indexez réellement.

1.1 Supprimer les champs inutiles

Ouvrez la configuration de votre index Search API et passez en revue chaque champ indexé. Pour chacun, posez-vous les questions suivantes :

Ce champ apparaît-il dans l'affichage des résultats de recherche?
Les utilisateurs recherchent-ils directement dans ce champ?
Ce champ est-il utilisé pour le filtrage ou les facettes?

Si un champ ne répond à aucun de ces objectifs, retirez-le de l'index. Des index plus petits signifient des requêtes plus rapides et une meilleure utilisation du cache.

1.2 Configurer des analyseurs spécifiques à la langue

Search API Solr fournit des ensembles de configuration avec des types de champs adaptés aux langues. Utilisez-les au lieu des champs génériques text_general.

Pour un site multilingue, configurez les types de champs comme ceci dans votre schéma :

<fieldType name="text_en" class="solr.TextField" positionIncrementGap="100">
  <analyzer type="index">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_en.txt"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.EnglishPossessiveFilterFactory"/>
    <filter class="solr.PorterStemFilterFactory"/>
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_en.txt"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.EnglishPossessiveFilterFactory"/>
    <filter class="solr.PorterStemFilterFactory"/>
  </analyzer>
</fieldType>

Notre expérience démontre que le passage d'analyseurs génériques à des analyseurs spécifiques à la langue améliore généralement les scores de pertinence de 15 à 25 % pour les sites avec un contenu textuel substantiel.

1.3 Créer des listes de synonymes personnalisées

Créez un fichier synonyms.txt avec des termes propres à votre domaine :

# Abréviations de produits
CMS, système de gestion de contenu
API, interface de programmation

# Termes de l'industrie
RH, ressources humaines
SEO, référencement naturel

# Votre terminologie spécifique
widget, composant, bloc

Placez ce fichier dans votre répertoire de configuration Solr et référencez-le dans l'analyseur de votre type de champ. Consultez les journaux de recherche trimestriellement pour identifier les termes que les utilisateurs cherchent mais qui ne correspondent pas au vocabulaire de votre contenu.

Étape 2 : Configurer les gestionnaires de requêtes pour une meilleure pertinence

Les paramètres de requête par défaut de Solr correspondent rarement à votre modèle de contenu spécifique. Ajuster le gestionnaire de requêtes fait une différence significative dans la qualité des résultats.

2.1 Configurer edismax avec pondération des champs

Dans votre fichier solrconfig.xml, configurez un gestionnaire de requêtes avec des poids de champs explicites :

<requestHandler name="/select" class="solr.SearchHandler">
  <lst name="defaults">
    <str name="defType">edismax</str>
    <str name="qf">title^5.0 field_tags^3.0 field_summary^2.0 body^1.0</str>
    <str name="pf">title^10.0 field_summary^3.0</str>
    <str name="mm">2<-1 5<-2 6<90%</str>
    <int name="ps">3</int>
  </lst>
</requestHandler>

Cette configuration :

Pondère les correspondances de titre 5 fois plus que les correspondances dans le corps
Applique un boost de phrase aux titres (10x) lorsque les mots apparaissent ensemble
Utilise des règles de correspondance minimale qui deviennent plus strictes avec les requêtes plus longues

2.2 Ajouter un boost de fraîcheur pour le contenu sensible au temps

Pour les sites de nouvelles, les blogues ou la documentation où la fraîcheur compte :

<str name="bf">recip(ms(NOW,ds_created),3.16e-11,1,1)</str>

Cela applique une fonction de décroissance basée sur la date de création. Le contenu d'hier obtient un meilleur score que le contenu de l'an dernier, toutes choses étant égales par ailleurs.

Pour plus de contrôle, utilisez un boost multiplicatif :

<str name="boost">if(exists(bs_featured),2,1)</str>

Cela double le score pour tout contenu marqué comme « vedette » dans Drupal.

2.3 Configurer l'autocomplétion séparément

Créez un gestionnaire dédié pour les suggestions de saisie automatique :

<requestHandler name="/autocomplete" class="solr.SearchHandler">
  <lst name="defaults">
    <str name="defType">edismax</str>
    <str name="qf">title^3.0 spell</str>
    <str name="rows">10</str>
    <str name="fl">title,url</str>
  </lst>
</requestHandler>

L'autocomplétion devrait retourner un minimum de champs (titre et URL seulement) et interroger un ensemble de champs plus restreint pour des temps de réponse plus rapides.

Étape 3 : Implémenter une mise en cache efficace

La mise en cache se produit à plusieurs niveaux. Configurez chacun d'eux de façon appropriée.

3.1 Ajuster les caches internes de Solr

Dans solrconfig.xml, ajustez les tailles de cache en fonction de vos patrons de requêtes :

<filterCache class="solr.FastLRUCache"
             size="512"
             initialSize="512"
             autowarmCount="256"/>

<queryResultCache class="solr.LRUCache"
                  size="512"
                  initialSize="512"
                  autowarmCount="256"/>

<documentCache class="solr.LRUCache"
               size="512"
               initialSize="512"/>

Surveillez les taux de succès du cache via l'interface d'administration de Solr. Si les succès du cache de filtres sont inférieurs à 80 %, augmentez la taille du cache ou réduisez la cardinalité des facettes.

3.2 Configurer les facettes pour l'efficacité du cache

Dans la configuration des Facettes de Drupal, privilégiez les champs à faible cardinalité :

Bons candidats pour les facettes :

Type de contenu (typiquement 5-20 valeurs)
Catégorie/taxonomie (dizaines à quelques centaines)
Année de publication (plage limitée)
Auteur (si le nombre est raisonnable)

Mauvais candidats pour les facettes :

Étiquettes (potentiellement des milliers de valeurs)
Dates individuelles (sans limite)
Libellés générés par les utilisateurs

Chaque combinaison unique de facettes crée une entrée de cache séparée. Moins de facettes avec moins de valeurs signifie une meilleure utilisation du cache.

3.3 Activer la mise en cache du rendu Drupal pour les résultats

Même lorsque la page de résultats de recherche varie selon la requête, les éléments de résultats individuels peuvent être mis en cache :

function mymodule_preprocess_search_result(&$variables) {
  $variables['#cache']['keys'][] = 'search_result';
  $variables['#cache']['keys'][] = $variables['result']['node']->id();
  $variables['#cache']['contexts'][] = 'user.permissions';
  $variables['#cache']['tags'][] = 'node:' . $variables['result']['node']->id();
}

Cela met en cache le HTML rendu pour chaque élément de résultat, ne le reconstruisant que lorsque le nœud sous-jacent change.

Étape 4 : Configurer l'indexation pour les charges de production

Comment et quand vous indexez le contenu affecte à la fois la fraîcheur de la recherche et la performance du site.

4.1 Configurer les stratégies de validation

Utilisez des validations douces (soft commits) pour une disponibilité de recherche quasi temps réel :

<autoSoftCommit>
  <maxTime>1000</maxTime>
</autoSoftCommit>

<autoCommit>
  <maxTime>60000</maxTime>
  <openSearcher>false</openSearcher>
</autoCommit>

Les validations douces rendent les documents cherchables en moins d'une seconde. Les validations dures écrivent sur le disque toutes les 60 secondes mais ne rouvrent pas le chercheur (ce qui invaliderait les caches).

4.2 Gérer le traitement de la file d'indexation

Dans Drupal, configurez le traitement d'index de Search API :

// Dans settings.php ou un module personnalisé
$config['search_api.index.your_index']['options']['index_directly'] = FALSE;
$config['search_api.index.your_index']['options']['cron_limit'] = 100;

Cela met les éléments en file d'attente pour un traitement par lots plutôt que d'indexer à chaque sauvegarde de nœud. Traitez la file pendant les périodes de faible trafic :

# Exécuter via cron à 2h du matin
0 2 * * * drush search-api:index your_index --limit=5000

4.3 Planifier les réindexations complètes de façon appropriée

Les réindexations complètes devraient avoir lieu :

Après des modifications de schéma
Après des migrations de contenu majeures
Après des mises à niveau de Solr

Planifiez-les pendant les fenêtres de maintenance :

drush search-api:reset-tracker your_index
drush search-api:index your_index --batch-size=100

Utilisez --batch-size pour contrôler l'utilisation de la mémoire et éviter les délais d'expiration.

Erreurs courantes à éviter

Après avoir travaillé sur des dizaines d'implémentations Drupal/Solr, certains patrons causent invariablement des problèmes.

Indexer tout « au cas où »

Ajouter des champs à l'index parce qu'ils pourraient être utiles plus tard crée des index gonflés et des requêtes plus lentes. Nous avons constaté qu'un élagage agressif—retirer tout champ qui n'est pas activement utilisé pour la recherche, les facettes ou l'affichage—améliore généralement la performance des requêtes de 30 à 50 %.

Utiliser des facettes à haute cardinalité

Facetter sur un champ avec des milliers de valeurs uniques (comme des étiquettes en texte libre) détruit la performance du cache. Chaque combinaison de facettes sélectionnées crée une nouvelle entrée dans le cache de filtres. Convertissez les champs à haute cardinalité en taxonomies organisées ou retirez-les des facettes.

Ignorer les journaux de requêtes

Solr enregistre chaque requête. Exportez-les mensuellement et analysez :

Les requêtes retournant zéro résultat (candidats pour les synonymes)
Les requêtes avec des taux de raffinement élevés (problèmes de pertinence)
Les requêtes lentes (problèmes possibles de champs ou de gestionnaires)

Ces données devraient guider vos décisions d'optimisation, pas des suppositions sur le comportement des utilisateurs.

Traiter Solr comme « configurer et oublier »

La performance de recherche se dégrade à mesure que le contenu croît et que les patrons d'utilisation changent. Prévoyez des cycles de révision trimestriels : vérifiez les taux de succès du cache, analysez les journaux de requêtes lentes, mettez à jour les synonymes et ajustez les pondérations des champs.

Exécuter des réindexations pendant les pics de trafic

Les opérations d'indexation lourdes rivalisent avec les requêtes pour les ressources de la JVM. Planifiez toujours l'indexation en lot pendant les périodes de faible trafic et utilisez des tailles de lots qui ne surchargent pas la mémoire disponible.

Tests et vérification

Après avoir implémenté les changements, vérifiez qu'ils fonctionnent comme prévu.

Mesurer la performance des requêtes

Utilisez l'interface d'administration de Solr pour tester les requêtes directement :

Allez dans l'administration Solr → votre collection → Query
Exécutez des requêtes échantillons correspondant aux recherches réelles des utilisateurs
Vérifiez le QTime dans la réponse (devrait être sous 100 ms pour les requêtes typiques)
Examinez la sortie de débogage pour vérifier que les valeurs de boost sont correctement appliquées

Vérifier l'efficacité du cache

Dans l'administration Solr → votre collection → Plugins → Cache :

Le taux de succès du cache de filtres devrait dépasser 80 %
Le taux de succès du cache de résultats de requêtes devrait dépasser 70 %
Si les taux sont bas, augmentez les tailles de cache ou révisez les patrons de requêtes

Tester les temps de réponse de bout en bout

Depuis Drupal, mesurez le chargement complet de la page de recherche :

$start = microtime(true);
$results = $index->query($query)->execute();
$solr_time = microtime(true) - $start;
\Drupal::logger('search_perf')->info('Temps de requête : @time ms', [
  '@time' => round($solr_time * 1000),
]);

Visez des temps de réponse P95 sous 500 ms pour l'opération de recherche complète, incluant le traitement Drupal.

Surveiller la performance en continu

Configurez des alertes pour :

Un temps de requête moyen dépassant la référence de 50 %
Un arriéré de file d'indexation dépassant 1000 éléments
Des taux de succès du cache tombant sous 70 %
Une augmentation des taux d'erreur Solr

Les équipes avec lesquelles nous travaillons rapportent que la surveillance proactive détecte les problèmes avant que les utilisateurs ne remarquent une dégradation de la qualité de recherche.

Conclusion

Améliorer la recherche Solr dans Drupal repose sur une configuration réfléchie à chaque niveau : une conception de schéma qui correspond à votre modèle de contenu, des gestionnaires de requêtes ajustés pour vos exigences de pertinence, une mise en cache configurée pour vos patrons de trafic et des pratiques opérationnelles qui maintiennent la performance à mesure que votre site grandit.

Les techniques couvertes ici—élagage des champs, analyseurs spécifiques aux langues, ajustement d'edismax, configuration du cache et surveillance structurée—adressent les problèmes de performance les plus courants que nous voyons sur les sites Drupal en production. Commencez par les modifications de schéma et l'ajustement des gestionnaires de requêtes, car ceux-ci livrent généralement les améliorations les plus importantes avec le moins de changements d'infrastructure.

Bien configurer la recherche Solr nécessite de comprendre à la fois comment les utilisateurs recherchent réellement et comment votre contenu est structuré. Si votre équipe travaille sur des problèmes de performance de recherche ou planifie une mise à niveau de l'infrastructure de recherche, nous pouvons vous aider à auditer votre configuration actuelle, identifier les améliorations à fort impact et implémenter les changements sans perturber votre environnement de production. Contactez-nous pour discuter de vos besoins spécifiques en matière de recherche.

Approches concrètes pour améliorer la recherche Solr dans Drupal