Meilleures pratiques en matière de performances et de capacités de l'index de génération pour les clients à volume élevé
Une implémentation HCL Commerce à volume élevé peut inclure un grand volume de catalogue, un grand nombre de langues et un temps limité pour générer l'index de recherche. En effectuant une planification minutieuse de la capacité et en suivant les meilleures pratiques de performance, vous pouvez optimiser les performances et la capacité pour HCL Commerce version 9.0.1.3 et ultérieures.
Meilleures pratiques en matière de planification des capacités
Ressources d'UC
La génération de l'index de recherche est une procédure qui nécessite un calcul intensif de l'UC. Pour générer un index avec de nombreuses langues en peu de temps, vous devez utiliser le traitement et la fragmentation parallèles. La génération d'index HCL Commerce Search prend en charge le traitement parallèle et la fragmentation. Pour plus d'informations, voir https://help.hcltechsw.com/commerce/9.0.0/search/concepts/csdsearchparallel.html.
Les ressources de l'UC sont le premier facteur à prendre en compte lorsque vous prévoyez d'optimiser les performances, y compris les meilleures pratiques suivantes.
- Déterminer le numéro du fragment
En général, le traitement des différentes langues se fait en parallèle. Avec suffisamment de ressources matérielles, la durée de l'index de génération totale pour plusieurs langues est la même que celle de la génération d'une langue. Lorsque la fragmentation est utilisée, toute la procédure d'index de génération est divisée en trois étapes : prétraitement, indexation et fusion. La durée du prétraitement et de la fusion est à peu près égale à la durée de l'indexation, et la vitesse d'indexation s'élève à entre 1 million et 1,5 million de documents par heure. Cet exemple utilise une estimation prudente de 0,5 million de documents par heure pour calculer la durée totale de l'index de génération.
Pour de nombreuses implémentations HCL Commerce, il existe beaucoup plus de documents d'index d'entrée de catalogue que de documents d'index de groupe de catalogues. Cet exemple ne tient compte que de la génération d'index d'entrée de catalogue, car la génération d'index parallèle prend en charge uniquement le noyau d'entrée de catalogue.
Dans cet exemple, le catalogue d'index de génération contient 6 millions d'entrées de catalogue (y compris les produits, les numéros SKU, les groupements et d'autres entrées), et le délai cible pour effectuer la génération est de 3 heures. Dans ce scénario, le numéro du fragment nécessaire est 6/3/0.5, ce qui équivaut à quatre fragments. Pour réduire le temps de génération à 1,5 heure, vous devez augmenter le nombre de fragments à 8 (6/1,5/0,5=8).
- Déterminer le nombre d'unités d'exécution actives et le nombre d'UC virtuelles (VCPU)Dans cet exemple, HCL Commerce contient 6 millions d'entrées de catalogue, un délai de 3 heures pour générer l'index et 10 langues à générer. Dans ce scénario, vous avez besoin de 40 unités d'exécution actives (4 multipliés par 10) pour effectuer le traitement parallèle de l'indexation, qui est la partie la plus intensive de l'ensemble de la procédure.Remarque : Le prétraitement nécessite plus d'unités d'exécution actives et la fusion nécessite moins d'unités d'exécution actives.
Vous devez également allouer 1-2 VCPU par chaque unité d'exécution active. Pour plus d'informations, voir https://help.hcltechsw.com/commerce/9.0.0/admin/concepts/cpmdockertune.html. Si vous allouez deux VCPU par unité d'exécution active, le traitement est plus rapide que l'allocation de 1 VCPU par unité d'exécution de travail.
L'indexation est exécutée dans le Docker du serveur de recherche. Ainsi, dans cet exemple, vous allouez 40-80 VCPU au total pour les Dockers du serveur de recherche. S'il y a huit Dockers de serveur de recherche, chaque Docker se voit attribuer 5-10 VCPU.
Ensuite, vous pouvez déterminer l'allocation de ressources de l'UC pour le serveur de base de données et le Docker d'utilitaire, là où le prétraitement s'exécute. La meilleure pratique consiste à allouer 50 à 100 % de VCPU des Dockers de serveur de recherche au serveur de base de données (ce qui équivaut à 40-80 VCPU dans ce scénario). En outre, il est préférable d'allouer 25 à 50 % de VCPU des Dockers serveur de recherche au Docker d'utilitaire (ce qui équivaut à 20-40 VCPU pour ce scénario).
- Envisager de traiter par lots la génération de l'index
Si vous disposez de moins de ressources matérielles disponibles et d'un délai plus détendu, ou si le nombre total de langues est trop important pour être traité en parallèle, vous pouvez envisager de traiter la génération d'index par lots.
Dans l'exemple de scénario (dans lequel il y a 6 millions d'entrées de catalogue et 10 langues), supposons que le délai d'index de génération est de 6 heures au lieu de 3 heures. Dans ce cas, vous pouvez diviser l'ensemble de la procédure de génération d'index en deux lots, chaque lot contenant cinq langues. Fractionner la procédure en lots réduit la ressource de l'UC à la moitié de ce qui était initialement requis. Pour répartir la génération en lots, divisez le fichier parallèle de propriétés de prétraitement en deux fichiers distincts (chacun contenant cinq langues) et élaborez un fichier de traitement par lots pour fractionner les procédures d'index de génération une par une avec les différents fichiers de propriétés.
Stockage des ressources
Les données d'entrée utilisées pour générer l'index sont stockées dans le serveur de base de données en tant que fichier de données, tandis que les données de sortie de l'index sont stockées dans le serveur de recherche en tant que fichier d'index. Les fichiers d'entrée et de sortie sont stockés dans le système de fichiers physiques, et lorsqu'il y a une grande quantité de données à générer, les E/S du disque sont intensives. Cet accès E/S pendant la génération d'index est aléatoire, et il est préférable d'utiliser le stockage Solid State Disk (SSD) au lieu du stockage Hard Disk Drive (HDD) pour la base de données et les serveurs de recherche. Le stockage SSD vous offre une bande passante E/S par seconde (IOPS) plus élevée.
En plus de la bande passante IOPS, la bande passante totale de lecture et d'écriture (Mo par seconde) est également importante. Pour le serveur de base de données, la plupart des E/S de disque se produisent pendant le prétraitement. Pour le serveur de recherche, la plupart des E/S du disque se produisent pour la fusion. Chaque procédure doit lire une grande quantité de données à partir du disque et écrire une grande quantité de données dans un court laps de temps.
La bande passante de lecture/d'écriture réelle iOPS est déterminée par la taille moyenne des données de chaque SKU (y compris les bits d'identificateur, la longueur des noms d'attribut et de valeur, la longueur de la description, etc.). Cet exemple de scénario fournit un numéro à titre de référence uniquement. Le calcul de votre implémentation doit s'appuyer sur vos valeurs.
Pour le magasin d'exemples HCL Commerce, la taille moyenne des fichiers d'index pour chaque entrée de catalogue est de 5 Ko avant la fusion et de 3 Ko après la fusion. Pour le client échantillon avec 6 millions d'entrées de catalogue, 10 langues et un délai de 3 heures, la procédure de fusion représente environ un quart de l'ensemble de la procédure. Dans ce scénario, la procédure de fusion prend environ 45 minutes (2 700 secondes). La procédure de fusion doit lire 300 Go (5 Ko multipliés par 6 millions d'entrées de catalogue multipliées par 10 langues) à partir du disque et écrire 180 Go (3 Ko multipliés par 6 millions multipliés par 10 langues) sur disque en 2 700 secondes. L'E/S du disque n'est pas répartie uniformément pendant la procédure de fusion. Par conséquent, la quantité de bande passante d'E/S allouée doit être et au moins deux fois supérieure au nombre prévu.
Ressources mémoire
Même si vous utilisez un stockage SSD haute vitesse, l'opération d'E/S du disque est encore beaucoup plus lente que si vous utilisez l'opération en mémoire. Par conséquent, la meilleure pratique pour les ressources de mémoire des serveurs de base de données et de recherche est que plus il y en a, mieux c'est. Vous obtenez de meilleures performances si le serveur de base de données dispose de suffisamment de mémoire pour contenir l'ensemble du fichier de base de données en mémoire et que le serveur de recherche est en mesure de contenir l'ensemble du fichier d'index en mémoire. En général, un nombre de ressources de mémoire moins élevé provoque plus d'opérations d'E/S de disque et ralentit toute la procédure d'index de génération.
Ressources réseau
Au cours de la procédure d'index de génération, la grande quantité de données qui est lue et écrite sur le disque est également transférée via le réseau (entre le serveur de base de données et le Docker d'utilitaire, et entre le serveur de base de données et le serveur de recherche).
Pour un client à volume élevé, Gigabit Ethernet est nécessaire en tant que connexion réseau entre le serveur de base de données et le Docker d'utilitaire, ainsi qu'entre le serveur de base de données et le serveur de recherche. Si vous avez des exigences plus difficiles, il est préférable d'utiliser plusieurs lignes de connexion ou 10 Gigabit Ethernet pour éviter que des goulots d'étranglement ne se produisent lors des transferts réseau.
Optimisation des performances
Utilisez toujours la dernière version de HCL Commerce pour utiliser les améliorations de performances les plus récentes dans le code du produit.
En outre, suivez ces meilleures pratiques générales afin d'atteindre les performances optimales pour la génération d'index à volume élevé.
- Prétraitement avec le Docker d'utilitaire
- Activer le prétraitement sur plusieurs unités d'exécution en définissant Global.preprocessing-multithread=true dans di-parallel-process.properties.
- Activez le prétraitement à plusieurs unités d'exécution pour toutes les langues en définissant Global.preprocessing-locale=en_US,ja_JP,de_DE (paramètres régionaux séparés par des virgules).Important : Si ce paramètre est défini sur Global.preprocessing-locale=all, les langues seront traitées de façon séquentielle.
- Adaptez les fichiers XML de configuration de prétraitement pour contrôler le nombre d'unités d'exécution actives parallèles. Pour plus d'informations, voir la section Contrôle du nombre d'unités d'exécution actives de prétraitement.
- Utilisez CopyColumnsDataPreProcessor pour la plupart des tables. CopyColumnsDataPreProcessor est la valeur par défaut pour HCL Commerce version 9.0.1.3 et ultérieures.
- Pour Db2®, désactivez le journal des transactions pour CopyColumnsDataPreProcessor.
- Augmentez le nombre fetchSize et batchSize pour non-CopyColumns DataPreProcessor.
- Indexation avec le Docker serveur de recherche
- Augmentez batchSize (solr.dih.batchSize), qui est défini comme une option JVM globale ou un paramètre de niveau de base dans la table SRCHCONFEXT de la base de données.
- Serveur de base de données
- Pour Db2®, activez le parallélisme intra-partition pour en définissant INTRA_PARALLEL=YES dans dbm cfg.
Contrôle du nombre d'unités d'exécution actives de prétraitement
Selon les résultats des tests d'environnement de laboratoire, le serveur de base de données n'est pas linéairement extensible pour un traitement parallèle pendant le prétraitement. Une fois le point de saturation atteint, si vous augmentez le nombre d'unités d'exécution actives, cela peut causer un impact négatif sur les performances. Lorsque vous activez le parallélisme intra-partition dans Db2®, il existe plusieurs unités de travail dans le serveur Db2® pour chaque unité de travail de prétraitement. Par conséquent, il est important de contrôler le nombre d'unités d'exécution actives de prétraitement pour atteindre des performances optimales de l'index de génération.
Lorsque le prétraitement sur plusieurs unités d'exécution est désactivé, il existe une unité d'exécution active de prétraitement par fragment et par langue. Mais, lorsque le prétraitement sur plusieurs unités d'exécution est activé, il existe plusieurs unités d'exécution actives de prétraitement par fragment et par langue. Le comportement du code produit HCL Commerce consiste à créer une unité d'exécution active pour chaque XML de configuration de prétraitement (tel que wc-dataimport-preprocess-attribute.xml). Les exemples de fichiers XML de prétraitement sont organisés par relation de table plutôt que par considération de performance. Vous pouvez diviser ou fusionner différents fichiers XML en fonction de vos considérations de performance.
De la version 9.0.1.2+, le prétraitement est divisé en deux phases. La première phase consiste à traiter des tables indépendantes de la langue (ce qui n'arrive qu'une seule fois). La deuxième phase concerne le traitement les tables dépendantes de la langue, lors duquel toutes les langues sont traitées en parallèle.
Pour la première phase, le nombre total d'unités d'exécution actives est égal au nombre XML multiplié par le nombre de fragments. Pour la deuxième phase, le nombre total d'unités d'exécution actives est égal au nombre XML multiplié par le nombre de fragments multiplié par le nombre de langues. Lorsqu'il existe de nombreuses langues pour le traitement parallèle, le nombre d'unités d'exécution actives peut être différent entre les deux phases.
En général, vous pouvez fractionner des fichiers XML de tables indépendantes de la langue et fusionner des fichiers XML de tables dépendantes de la langue pour équilibrer le numéro d'unités d'exécution actives des deux phases. Par exemple, tous les fichiers XML de tables dépendants de la langue sont fusionnés dans un seul XML. De cette façon, le nombre total d'unités d'exécution actives dans la deuxième phase est égal au nombre de fragments multipliés par le nombre de langues.