Rapport de recherche sur l'état de la recherche sur site dans l'enseignement supérieur avec The Chronicle of Higher Education | Télécharger le rapport
Rapport de recherche sur l'état de la recherche sur site dans l'enseignement supérieur avec The Chronicle of Higher Education | Télécharger le rapport

1er mars 2023

Dipsy Kapoor

|

3 min de lecture

La performance de votre Recherche Solr Votre implémentation est lente et avance à un rythme d'escargot ? Vous rencontrez des erreurs de mémoire insuffisante inattendues, des problèmes de récupération spontanée ou des performances d'indexation lentes ?

Quels sont les signes de problèmes de performances de recherche Solr ?

Les problèmes de configuration de la recherche Solr sont complexes et les solutions pour les résoudre sont parfois subtiles. Les paramètres solrconfig.xml peuvent être à l'origine de nombreux problèmes de performances. Les valeurs par défaut suggérées par le système sont parfois de mauvais choix et peuvent entraîner une utilisation intensive et durable du processeur ou une surcharge de la mémoire JVM.

Les commits durs trop fréquents, avec leur charge massive sur le processeur et les E/S disque, sont les plus problématiques. Heureusement, ce problème, comme bien d'autres, peut être facilement résolu en suivant les bonnes pratiques pour optimiser ou optimiser les performances de recherche Solr.

Suivez ces cinq recommandations pour optimiser vos paramètres solrconfig.xml et éviter les problèmes de performances de recherche Solr les plus courants :

  • Définir la fonction autoSoftCommit sur 2 minutes
  • Définissez la fonction autoCommit sur 5 minutes
  • Utilisez autowarmCount = 0 pour tous les paramètres de cache
  • Définir maxRamMB à 200
  • Utilisez les valeurs par défaut de True pour les champs paresseux et les requêtes triées

1. Définissez la fonction autoSoftCommit sur 2 minutes

Une validation logicielle (soft commit) permet une indexation en temps quasi réel (NRT) en ouvrant un nouveau moteur de recherche après un intervalle de temps spécifique. Plus rapide et moins coûteuse qu'une validation matérielle, elle n'écrit pas l'index sur le disque et ne crée pas de nouveau journal de transactions. Cependant, même si elle est moins coûteuse, elle consomme des ressources et doit être configurée aussi longtemps que possible pour l'application.

Nous vous recommandons de régler cette fonctionnalité sur deux minutes ou 120 000 millisecondes.

				
					<autoSoftCommit> <maxTime>120000</maxTime> </autoSoftCommit>
				
			

2. Définissez la fonction autoCommit sur 5 minutes

Une validation matérielle écrit l'index en mémoire sur le disque. Elle ferme le journal des transactions actuel et en ouvre un nouveau. Il est préférable de ne pas effectuer cette opération trop fréquemment, car elle prend beaucoup de temps.

Nous vous recommandons de vous engager après au moins cinq minutes.

Si autoSoftCommit est activé (par défaut) et ouvre un nouveau moteur de recherche à chaque validation logicielle. Les validations logicielles étant plus fréquentes que les validations matérielles, il n'est pas nécessaire d'ouvrir également des moteurs de recherche pour les validations matérielles. Nous recommandons donc de définir openSearcher signaler comme faux.

				
					<autoCommit> <maxTime>300000</maxTime> <openSearcher>false</openSearcher> </autoCommit>
				
			

3. Utilisez autowarmCount = 0 pour tous les paramètres de cache

Les caches de requêtes–filtreCachequeryResultCache, et documentCache–stocker les résultats de la requête pour une récupération plus rapide lors des recherches ultérieures.

Nous vous recommandons de définir autowarmCount sur zéro pour tous les paramètres de cache.

				
					<filterCache class="solr.FastLRUCache" size="512" initialSize="512" autowarmCount="0"/> <queryResultCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0"/> <documentCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0"/>
				
			

4. Définissez maxRamMB sur 200

Le queryResultCache dispose d'un paramètre optionnel supplémentaire, maxRamMB. Cette fonctionnalité peut être définie pour garantir que le cache ne consomme pas trop de mémoire, ce qui peut se produire dans les cas où de grands champs stockés sont renvoyés dans le cadre du résultat de la requête.

Nous recommandons également d’utiliser la valeur par défaut de 200 pour queryResultMaxDocsCached.

5. Utilisez les valeurs par défaut True pour les champs paresseux et les requêtes triées

Le activerLazyFieldLoading Ce paramètre permet à Solr de charger ultérieurement, si nécessaire, des champs non directement demandés. Cela peut améliorer les performances si la plupart des requêtes ne demandent qu'un petit sous-ensemble de champs.

Nous vous recommandons de laisser le activerLazyFieldLoading avec la valeur par défaut de vrai.

				
					<enableLazyFieldLoading>true</enableLazyFieldLoading>
				
			

Il peut arriver que la même requête soit demandée plusieurs fois, mais avec un champ de tri et un ordre différents. utiliserFilterForSortedQuery dans ces scénarios, cela peut améliorer les performances car Solr utiliserait un filtre pour satisfaire la recherche et mettre en cache les résultats.

Nous recommandons que utiliserFilterForSortedQuery devrait être laissé tel quel vrai.

				
					<useFilterForSortedQuery>vrai</useFilterForSortedQuery>
				
			

SearchStax Cloud est une solution SaaS entièrement gérée qui automatise, gère, maintient et fait évoluer l'infrastructure de recherche Solr dans les clouds publics ou privés. Planifier une démonstration pour voir par vous-même la puissance de Solr hébergé ou Contactez-nous pour parler avec l'un de nos experts en recherche.

Par Dipsy Kapoor

vice-président, ingénierie

« Les problèmes de configuration de la recherche Solr sont complexes et les prescriptions pour les résoudre sont parfois subtiles. »

Vous aimerez peut-être aussi :

fr_CAFrançais du Canada