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 produit17 mars 2020
Dipsy Kapoor
|
Solr devient de plus en plus un moteur de recherche de facto pour Implémentations Sitecore en raison de ses performances, de ses fonctionnalités, de sa personnalisation et de son évolutivité. Cependant, si Solr n'est pas configuré ou utilisé correctement, les applications peuvent rencontrer des problèmes de performances.
Les performances de votre implémentation de recherche Solr sont-elles lentes et ralenties ? Rencontrez-vous 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 recherche Solr sont complexes et les solutions pour les résoudre sont parfois subtiles. Grâce à notre solide expérience des configurations Solr chez SearchStax, nous avons appris que solrconfig.xml Les paramètres sont à 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 importante 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 sur Sitecore.
Suivez ces cinq recommandations SearchStax pour optimiser votre solrconfig.xml Paramètres et évitez les problèmes de performances de recherche Solr les plus courants avec Sitecore. Découvrez-en plus sur chacun d'entre eux ci-dessous.
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 recommandons de définir cette fonctionnalité sur deux minutes ou 120 000 millisecondes.
120 000
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 recommandons de valider 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.
300 000 FAUX
À mesure que la taille de vos collections augmente, Solr peut ne pas être en mesure de créer un instantané de l'index en 5 minutes. Dans ce cas, pour des sauvegardes régulières, vous devrez peut-être augmenter les paramètres de validation : 5 minutes pour les validations logicielles et 10 minutes pour les validations matérielles.
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 recommandons de définir la valeur autowarmCount à zéro pour tous les paramètres de cache.
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.
200
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.
vrai
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.
vrai
Si vous souhaitez en savoir plus sur les meilleures pratiques pour optimiser les performances de Solr, consultez ces ressources supplémentaires :
Laissez-nous résoudre les aspects techniques de votre infrastructure Solr pour Sitecore. Recherche gérée SearchStaxNous nous efforçons de vous garantir une configuration Solr fiable, sécurisée et conforme. Créez des sauvegardes, des plans de reprise après sinistre et surveillez les alertes pour vous concentrer sur des projets plus importants.
The Stack est livré tous les deux mois avec des tendances du secteur, des informations, des produits et plus encore