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
La solution SearchStax Site Search offre aux spécialistes du marketing l'agilité dont ils ont besoin pour optimiser les résultats du site Web.
Présentation du produitSearchStax Managed Search décharge la gestion de Solr, offrant aux équipes informatiques une agilité opérationnelle accrue.
Présentation du produit1er mars 2023
Dipsy Kapoor
|
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 ?
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 :
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>
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>
Les caches de requêtes–filtreCache, queryResultCache, 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"/>
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.
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.
The Stack est livré tous les deux mois avec des tendances du secteur, des informations, des produits et plus encore