HCL Commerce Search : optimisation des performances

Quand effectuer des générations d'index de recherche complet

L'index HCL Commerce Search est automatiquement créé lorsque certaines tâches métier sont exécutées, comme indiqué dans Tâches métier courantes et leur impact sur l'index HCL Commerce Search. Dans plusieurs cas, les tâches métier courantes se traduisent par des données d'index delta qui ne présentent pas de risque important pour les performances du système de production. Toutefois, le fait de générer plusieurs index delta sans générer occasionnellement d'index complet pourrait entraîner une dégradation progressive de l'index de recherche au fil du temps en raison de la fragmentation. Pour éviter ce problème, effectuer des générations d'index de recherche complètes lorsque cela est possible garantit que l'index de recherche fonctionne correctement dans le temps.

Lorsque Lucene reçoit une requête de suppression, il ne supprime pas les entrées de l'index, mais les marque plutôt pour suppression et ajoute des enregistrements mis à jour à la fin de l'index. Ce marquage entraîne une répartition inégale du catalogue entre les différents fichiers de données de segment dans l'index de recherche et peut entraîner une augmentation des temps de réponse de recherche. Si vous disposez d'un serveur d'indexation dédié, envisagez de planifier une génération périodique d'index de recherche complet. Créez cette tâche de génération en arrière-plan qui s'exécute une fois par mois, afin que les entrées supprimées soient vidées et que les données soient optimisées.

Serveur d'indexation

Prenez en compte les facteurs suivants lorsque vous réglez le serveur d'indexation :

Le pré-processeur de génération d'index utilise maintenant Varchar comme type de zone plutôt que Clob

Le type de données de plusieurs colonnes de la table TI_ATTR a été modifié à partir de CLOB. Les six colonnes sont maintenant définies comme varchar(32672) dans Db2 et varchar2(32767) pour Oracle dans le fichier de configuration wc-dataimport-preprocess-attribute.xml. La même modification a été apportée dans la colonne ATTRIBUTES de TI_ADATTR. Cette modification réduit le temps de prétraitement de ces deux tableaux.

Cette modification exige que les utilisateurs d'Oracle activent la fonction "Types de données étendus" décrite dans https://oracle-base.com/articles/12c/extended-data-types-12cR1. Si vous migrez à partir d'une version précédente, assurez-vous de supprimer tous les tableaux temporaires avant de continuer.

Note: Vous devez également exécuter l'instruction en gras dans cet exemple. Dans le cas contraire, la base de données Oracle ne reviendra pas en ligne après un redémarrage.

CONN / AS SYSDBA SHUTDOWN IMMEDIATE; STARTUP UPGRADE; ALTER SYSTEM SET max_string_size=extended; @?/rdbms/admin/utl32k.sql SHUTDOWN IMMEDIATE; STARTUP; 

Un fichier de configuration x-data-config.xml est disponible et consolide les paramètres qui activent le prétraitement CLOB. Pour utiliser CLOB dans le prétraitement, supprimez la mise en commentaire des sections pertinentes.

• x-data-config.xml

Le pré-processeur CopyColumnsDataPreProcessor peut réduire le temps de traitement temporaire des tables de 50 %

Le pré-processeur utilise la syntaxe SQL pour éliminer la communication aller-retour inutile entre Java et la base de données. Cette syntaxe peut prendre le format : INSERT INTO <one table> SELECT FROM <another table>.

Pour activer le pré-processeur, copiez et utilisez les fichiers XML fournis.

• Pour activer le pré-processeur de votre pipeline CI/CD, commencez par copier les fichiers XML dans votre dossier d'exemples d'environnement de développement (boîte à outils). Copiez les fichiers XML depuis le répertoire samples/dataimport/copy_columns_data_preprocessor de votre environnement de développement vers le répertoire \WC\xml\search\dataImport de votre pipeline CI/CD.
  Note: Dans 9.0.1.1, le dossier samples/dataimport/copy_columns_data_preprocessor est déprécié. Tous les fichiers XML correspondants ont une copie dans le dossier \WC\xml\search\dataImport\v3\database\CatalogEntry (où database est db2 ou oracle). Les fichiers ont une extension .copycolumns dans la boîte à outils. Ils sont également disponibles dans /profile/installedApps/localhost/ts.ear/xml/search/dataImport/v3/database/CatalogEntry l'exécution des conteneurs Docker de serveur de transactions et d'utilitaire.
• Si vous souhaitez une évaluation rapide du pré-processeur, copiez les fichiers XML depuis votre conteneur du Docker d'utilitaire vers le répertoire /profile/installedApps/localhost/ts.ear/xml/search/dataImport de votre conteneur Docker du serveur de transactions. Vous pouvez effectuer cette procédure pour tester les résultats du pré-processeur dans votre pipeline CI/CD ou dans un environnement de développement.

La table suivante répertorie les fichiers XML qui utilisent le pré-processeur CopyColumnsDataPreProcessor et la ou les tables temporaires que chaque fichier peut optimiser.

Fichier XML	Table temporaire
wc-dataimport-preprocess-attribute.xml	TI_CATENTREL_#INDEX_SCOPE_TAG# TI_ADATTR_#INDEX_SCOPE_TAG#
wc-dataimport-preprocess-catalog.xml	TI_CATALOG_#INDEX_SCOPE_TAG# TI_CATALOGI_#INDEX_SCOPE_TAG#
wc-dataimport-preprocess-common.xml	TI_SEOURL_#INDEX_SCOPE_TAG#_#lang_tag#
wc-dataimport-preprocess-direct-parent-catentry.xml	TI_CATGPENREL_#INDEX_SCOPE_TAG# TI_DPCATENTRY_#INDEX_SCOPE_TAG# TI_GROUPING_#INDEX_SCOPE_TAG#
wc-dataimport-preprocess-direct-parent-catgroup.xml	TI_DPGROUPI_#INDEX_SCOPE_TAG# TI_DPGRPNAME_#INDEX_SCOPE_TAG#_#lang_tag#
wc-dataimport-preprocess-fullbuild.xml	TI_CATENTRY_#INDEX_SCOPE_TAG#
wc-dataimport-preprocess-fullbuild-workspace.xml	TI_D_CATENTRY_#INDEX_SCOPE_TAG# TI_CATENTRY_#INDEX_SCOPE_TAG#
wc-dataimport-preprocess-offerprice.xml	TI_OFFER_#INDEX_SCOPE_TAG#
wc-dataimport-preprocess-parent-catgroup.xml	TI_APGROUPI_#INDEX_SCOPE_TAG#
wc-dataimport-preprocess-productset.xml	TI_PRODUCTSET_#INDEX_SCOPE_TAG#

Important: Avant de générer un index, assurez-vous de supprimer toutes les tables temporaires.

Assurez-vous que le traçage est activé. Exécutez l'index comme d'habitude et utilisez le suivi pour déterminer les améliorations de performances qui se sont produites.

CopyColumnsDataPreProcessor peut s'appuyer fortement sur le calcul de base de données. Lorsque le prétraitement se produit, vous pouvez rencontrer des problèmes avec le traitement et voir l'erreur "SQLCODE=-964,". Cette erreur peut se produire lorsque vous n'avez pas suffisamment d'espace de journal pour le pré-processeur . Vous pouvez exécuter des instructions SQL au niveau de votre base de données pour augmenter l'espace journal.

La taille du journal des transactions de la base de données Db2 est contrôlée par LOGFILSIZ et LOGPRIMARY+LOGSECOND. Les instructions SQL suivantes fournissent un exemple de la manière d'augmenter l'espace du journal à 4 Ko*40000*(20+160)=28,8 Go :

 db2 update db cfg for <dbname> using LOGFILSIZ 40000 db2 update db cfg for <dbname> using LOGPRIMARY 20 db2 update db cfg for <dbname> using LOGSECOND 160

Dans HCL Commerce version 9.0.1.3, CopyColumnsDataPreProcessor est utilisé par défaut pour les tables applicables dans xml/search/dataImport/v3/db2/CatalogEntry.

Note: Les tables des anciens répertoires (Db2 et Oracle) utilisent toujours StaticAttributeDataPreProcessor.

Le journal de transactions est désactivé par défaut pour CopyColumnsDataPreProcessor. Le fragment XML suivant définit comment désactiver le journal des transactions pour Db2 :

 <_config:data-processing-config processor="com.ibm.commerce.foundation.dataimport.preprocess.CopyColumnsDataPreProcessor"> <_config:table definition="..." name="..."/> <_config:query sql="..."/> <_config:property name="no_logging_sql" value="alter table #TABLE_NAME# activate not logged initially" />  </_config:data-processing-config> 

Pour activer le journal de transactions spécifique à CopyColumnsDataPreProcessor, il suffit de supprimer la propriété no_logging_sql de la configuration. Dans cet exemple, la propriété no_logging_sql a été supprimée :

 <_config:data-processing-config processor="com.ibm.commerce.foundation.dataimport.preprocess.CopyColumnsDataPreProcessor"> <_config:table definition="..." name="..."/> <_config:query sql="..."/> </_config:data-processing-config>

CatalogHierarchyDataPreProcessor peut améliorer la vitesse de traitement lorsque le paramètre fetchSize est spécifié.

Dans HCL Commerce version 9.0.0.6, CatalogHierarchyDataPreProcessor est mis à jour pour améliorer les performances. Ce pré-processeur, qui est activé par défaut, est utilisé pour injecter des données traitées dans la table TI_APGROUP temporaire. TI_APGROUP devient inefficace dans les grands numéros de catalogue de vente car il itère une structure de données interne et émet une requête sur chaque itération. En spécifiant le paramètre fetchsize, vous pouvez améliorer la vitesse de traitement du pré-processeur jusqu'à 50 %. L'option fetchsize est un processus de sélection de lots qui utilise WHERE catentry_id dans n'importe quelle clause (?.?…?)

Les options fetchSize et batchSize par défaut du pré-processeur sont définies sur 500. L'option fetchSize ne peut pas être plus grande que 32767 pour Db2, ou 1000 pour Oracle.

Par exemple :

<_config:data-processing-config processor="com.ibm.commerce.foundation.dataimport.preprocess.CatalogHierarchyDataPreProcessor" masterCatalogId="10101" batchSize="500" fetchSize="1000"> ... </_config:data-processing-config>

La requête pour la table temporaire TI_ADATTR est modifiée dans la version 9.0.0.6+.

Pendant la génération de l'index, presque tous les appels rtrim() et cast() ont été supprimés de la requête pour la table TI_ADATTR temporaire. Ces appels étaient redondants pour les générations d'index ordinaires. La suppression de ces appels améliore le temps de réponse de cette requête par rapport aux bases de données Db2 et améliore la mise à l'échelle pour un grand nombre d'entrées de catalogue. La modification de cette requête est activée par défaut lorsque vous mettez à jour la version 9.0.0.6+.

Recherche de mise en cache pour le serveur d'indexation

En général, il faut désactiver tous les caches Solr sur le serveur d'indexation.

Réglage de la taille de la mémoire tampon de l'index et validation d'actions lors de l'importation de données (buildindex)

Vous pouvez régler votre fichier solrconfig.xml pour allouer suffisamment de mémoire pour la mise en mémoire tampon de l'index et empêcher les actions de validation lorsque vous générez votre index. Lorsque la mémoire tampon RAM pour les mises à jour d'index est pleine, Solr effectue des actions de validation qui conservent les données sur les disques. Lorsque ces actions de validation se produisent, Solr dispose d'un verrou exclusif global sur l'ensemble de votre JVM. Ce verrou empêche d'autres threads d'effectuer des opérations de mise à jour, même lorsque le thread travaille sur des enregistrements ou fichiers différents. Ce verrouillage peut augmenter le temps nécessaire à la génération de votre index. En augmentant la taille de votre mémoire tampon RAM et en désactivant le déclencheur de validation, vous pouvez réduire les risques que ce verrouillage ne se produise. Vous pouvez régler vos paramètres Solr pour les temps de validation et la taille de la mémoire tampon dans le fichier solrconfig.xml :

• Allouez plus de mémoire à la mise en mémoire tampon de l'index en modifiant la valeur du paramètre ramBufferSizeMB. La mémoire maximale pouvant être allouée est de 2 048 Mo :

  <ramBufferSizeMB>2048</ramBufferSizeMB>

• Désactivez le déclencheur de validation automatique côté serveur pour réduire également l'occurrence des actions de validation en commentant le déclencheur autoCommit :

  <!-- <autoCommit> <maxDocs>10000</maxDocs> <maxTime>1000</maxTime> </autoCommit> -->

Configuration de la taille du segment de mémoire de base de données et de pagination

Vérifiez si la taille de votre mémoire et de votre pagination est configurée en fonction de la taille des données de votre catalogue ou si votre environnement contient plusieurs index pour différentes langues. Par exemple, si vous rencontrez des problèmes d'accès ou de génération de grandes quantités de données d'index :

1. Augmentez la taille de pagination par défaut pour votre système d'exploitation. Par exemple, 3 GB. Dans les cas où le système d'exploitation nécessite une taille de pagination plus élevée, l'ajout de plus de mémoire au système aide également à résoudre les problèmes.
2. Augmentez la taille du segment de mémoire de base de données par défaut à une valeur plus grande. Par exemple, augmentez la taille du segment de mémoire Db2 à 8192.
3. Augmentez la limite du descripteur de fichiers à une valeur supérieure. Par exemple : ulimit -n 8192.

Configuration de la taille du segment de mémoire

Vérifiez si votre taille du segment de mémoire HCL Commerce Search est configurée en fonction de la taille des données de votre catalogue ou si votre environnement contient plusieurs index pour différentes langues. Par exemple, si vous rencontrez des problèmes d'accès à de grandes quantités de données d'index, augmentez la taille du segment de mémoire par défaut à une valeur plus grande telle que 1280 . Pour plus d'informations, voir Configuration de la taille du segment de mémoire JVM dans WebSphere Liberty .

Important:

• Ne dépassez pas 28 Go de taille du segment de mémoire par JVM, même lorsque vous utilisez un environnement 64 bits. Dans une JVM 64 bits, une fonction d'optimisation de référence compressée d'adresse qui pourrait être désactivée si l'espace du segment de mémoire dépasse 28 Go existe. Si elle est désactivée, il peut y avoir jusqu'à 30 % de dégradation du débit global.

Configuration de la taille du pool partagé

Assurez-vous que la valeur SHARED_POOL_SIZE est configurée en fonction de votre environnement. L'augmentation de la taille du pool partagé peut améliorer les performances du processus de génération d'index.

Par exemple :

 ALTER SYSTEM SET SHARED_POOL_SIZE='668M' SCOPE=BOTH 

Exécution sur plusieurs unités d'exécution des expressions de requête SQL

Envisagez d'activer les unités d'exécution multiples dans Db2 pour augmenter les performances lorsque vous prétraitez l'index de recherche.

Pour ce faire, définissez INTRA_PARALLEL=YES dans la configuration Db2 DBM. Du côté client de la base de données, mettez à jour la propriété source de données currentDegree sur ANY. L'utilitaire Configuration du traitement parallèle se trouve dans di-parallel-process.properties. Une instruction de configuration d'exemple est Database.jdbcURL=jdbc:db2://db:50000/mall:currentDegree=ANY. Pour plus d'informations, voir Common IBM Data Server Driver for JDBC and SQLJ properties for Db2 servers.

Serveur d'exécution de la recherche

Prenez en compte les facteurs suivants lorsque vous réglez le serveur d'exécution de recherche :

Mise en cache

Mise en cache de la recherche pour les serveurs subordonnés de la production d'exécution

La configuration de démarrage incluse dans le fichier solrconfig.xml CatalogEntry n'est conçue que pour un environnement de développement à petite échelle, tel que HCL Commerce Developer.

Lorsque vous redéployez cette configuration d'index dans un système à plus grande échelle, tel qu'un système de transfert ou de production, personnalisez au moins les paramètres de cache suivants :

• queryResultWindowSize
• queryResultMaxDocsCached
• queryResultCache
• filterCache (requis sur l'index du produit lorsqu'un index d'extension tel que Stock existe)
• documentCache (requis sur l'index du produit lorsqu'un index d'extension tel que Stock existe)

L'exemple suivant montre comment définir les tailles de cache pour l'index d'entrée de catalogue et son espace de segment de mémoire correspondant requis dans la JVM :

Taille de l'exemple de catalogues

Taille du catalogue

1,8 million d'entrées.

Nombre total d'attributs

2000

Nombre total de catégories

10000

Chaque produit contient

Vingt attributs.

Taille moyenne de chaque entrée de catalogue

10 ko

Exemple de calcul :

queryResultWindowSize

La taille de chaque page de résultats de recherche dans la vitrine, 12 articles par page par exemple. Ce résultat comprend deux pages de pré-extraction.

Cette action se traduit par une valeur queryResultWindowSize de 36 (3x12).

queryResultMaxDocsCached

Pour des performances optimales, définissez cette valeur sur la même valeur que queryResultWindowSize.

queryResultCache

La taille de chaque queryResultCache est de 4 octets par référence docId (int) x queryResultWindowSize, pour une valeur de 144 octets.

Attribuez des emplacements de cache de 10 M pour la mise en cache des trois premières pages de la requête principale.

Cette action entraîne une taille totale requise de 1,44 Go (144 B x 10 000 000) pour queryResultCache.

filterCache

Supposons qu'une taille moyenne des résultats de recherche corresponde à 5 % de la taille totale du catalogue de 1,8 M, soit 90 000.

La taille de chaque filterCache est de 4 octets par référence docId (int) x nombre aléatoire de résultats de recherche de 90 000, soit 360 Ko.

Affectez 5 000 entrées pour filterCache.

La taille totale requise pour filterCache se traduit par une valeur de 1,8 Go (360 Ko x 5 000).

Note: filterCache est requis sur l'index du produit lorsqu'un index d'extension tel que Stock existe, de sorte que le composant de requête fonctionne correctement.

documentCache

Supposons que la taille moyenne de chaque document d'entrée de catalogue soit de 10 Ko.

Affectez 5 % du catalogue entier à mettre en cache ou 100 000 entrées pour documentCache.

La taille totale requise pour documentCache se traduit par une valeur de 1,0 Go (10 Ko x 100000).

Note:

• Définissez la taille de documentCache sur au moins la taille maximale prévue d'un résultat de recherche.
• documentCache est requis sur l'index du produit lorsqu'un index d'extension tel que Stock existe, de sorte que le composant de requête fonctionne correctement.

Par conséquent, la taille du segment de mémoire JVM estimée requise pour chaque noyau d'entrée de catalogue est de 4,3 Go (1,44 Go + 1,8 Go + 1,0 Go).

Gestion des tailles de cache pour se conformer à la mémoire JVM

Assurez-vous de configurer la valeur fieldValueCache du noyau d'index d'entrée de catalogue dans le fichier solrconfig.xml. Cette configuration peut éviter les problèmes de mémoire insuffisante en limitant sa taille pour se conformer à la mémoire JVM.

La taille du jeu de cache dépend de la quantité de zones de facettes et de la taille du catalogue. La taille de l'entrée du cache peut être calculée à peu près par la quantité d'entrées de catalogue dans le noyau d'index, qui est ensuite multipliée par 4 octets. Autrement dit, la quantité potentielle d'entrées de cache est égale à la quantité de facettes potentielles.

Par exemple, dans le fichier solrconfig.xml :

<fieldValueCache class="solr.FastLRUCache"
                 size="300"
                 autowarmCount="128"
                 showItems="32" />

Note: L'implémentation de la mise en cache solr.FastLRUCache recommandée n'a pas de limite stricte quant à sa taille. Elle est utile pour les caches qui ont des ratios d'accès élevés, mais qui peuvent dépasser de manière significative la valeur de taille que vous définissez. Si vous utilisez solr.FastLRUCache, surveillez l'utilisation de votre segment de mémoire pendant les périodes de pointe. Si le cache dépasse considérablement sa limite, envisagez de remplacer la classe fieldValueCache par solr.LRUCache pour éviter les problèmes de performance ou un problème de mémoire insuffisante.

Pour plus d'informations, voir https://https://lucene.apache.org/solr/guide/7_3/query-settings-in-solrconfig.html/solr/guide/6_6/query-settings-in-solrconfig.html.

Réglage du cache des données de pertinence de la recherche

Assurez-vous que vous réglez le cache de données de pertinence de recherche en fonction de la taille de votre catalogue.

Les données de pertinence sont stockées dans l'instance de cache suivante :

• services/cache/SearchNavigationDistributedMapCache

Chaque entrée varie de 8 à 10 Ko, et chacune contient entre 10 et 20 zones de pertinence. L'instance de cache contient également d'autres types d'entrées de cache. La base de données est utilisée pour chaque accès de page lorsque l'instance du cache est pleine, ce qui réduit les performances.

Réglage du cache de données de recherche pour la navigation à facettes

Le code de serveur HCL Commerce Search utilise la fonction de cache dynamique WebSphere pour effectuer la mise en cache des résultats de requête de base de données. Semblable au cache de données utilisé par le serveur HCL Commerce principal, ce code de mise en cache est appelé cache de données du serveur HCL Commerce Search.

Réglage de l'espace du segment de mémoire lorsque l'affichage du produit de recherche est activé

Par exemple, selon l'estimation de 15 Mo par catégorie, le séquençage manuel de 200 catégories avec une taille de catalogue de 100 k peut utiliser 3 Go de mémoire. Le séquençage manuel des mêmes 200 catégories peut utiliser 6 Go lorsque la taille du catalogue est de 1,1 million. Par conséquent, l'espace du segment de mémoire alloué par catégorie doit être ajusté en fonction de la taille du catalogue.

Performance des facettes

Index d'extension

Options de configuration

Configuration de la recherche

Assurez-vous que vous êtes familier avec les différents paramètres de configuration Solr, Solr Wiki: solrconfig.xml. La documentation contient des informations sur les personnalisations de configuration typiques qui peuvent potentiellement augmenter les performances de votre serveur de recherche. Par exemple, si votre magasin contient un nombre élevé de catégories ou de contrats, ou si votre serveur de recherche reçoit des erreurs Too many boolean clauses, augmentez la valeur par défaut pour maxBooleanClauses.

Indexation des modifications et autres considérations

Récupération de place

La stratégie du récupérateur de place par défaut pour la JVM HCL Commerce est Generational Concurrent Garbage Collector. En général, il n'est pas nécessaire de modifier cette politique.

Vous pouvez activer Generational Concurrent Garbage Collector pour la JVM HCL Commerce Search à l'aide de l'option ligne de commande -Xgcpolicy:gencon.

Note: L'utilisation d'une stratégie de récupération de place autre que Generational Concurrent Garbage Collector peut entraîner des situations où le temps de traitement des requêtes serait plus long et l'utilisation de l'UC plus élevée.

Pour plus d'informations, voir Stratégies ramasse-miettes.

Vérification orthographique

Vous pouvez ressentir un impact sur les performances lorsque vous activez la vérification orthographique pour les termes HCL Commerce Search.

Vous pourriez constater des gains de performance dans le débit des transactions si la vérification orthographique est ignorée lorsque cela est nécessaire, ou lorsque les utilisateurs recherchent des produits avec des remplacements de catalogues.

Par exemple, un terme de recherche qui est soumis dans une langue différente de celle de la vitrine nécessite des ressources pour la vérification orthographique. Toutefois, les noms de produits avec des remplacements de catalogues sont déjà connus et ne nécessitent aucune ressource pour la vérification orthographique.

Le composant du vérificateur orthographique, DirectSolrSpellChecker, utilise des données directement à partir de l'index CatalogEntry, au lieu de s'appuyer sur un index autonome et distinct.

Amélioration des performances de l'aperçu du magasin pour les modifications de recherche

Pour améliorer les performances lorsque vous prévisualisez les modifications de recherche, vous pouvez ignorer l'indexation du contenu non structuré lorsque les utilisateurs professionnels démarrent l'aperçu du magasin :

Dans le fichier wc-component.xml, définissez la propriété IndexUnstructured sur false.

Pour plus d'informations, voir Modification des propriétés dans le fichier de configuration du HCL Commerce (wc-component.xml).

Suivi des performances