HCL Commerce Search : ajuste del rendimiento

Cuándo se deben realizar creaciones de índice de búsqueda completas

El índice de HCL Commerce Search se crea automáticamente cuando se realizan determinadas tareas de negocio, tal como se describe en Tareas de negocio comunes y su impacto en el índice de HCL Commerce Search. Sin embargo, si se realizan varias creaciones de índice delta sin creaciones de índice completo ocasionales, es posible que el índice de búsqueda se degrade gradualmente a lo largo del tiempo debido a la fragmentación. Para evitar este problema, si se realizan creaciones de índice de búsqueda completas cuando es posible se garantiza que el índice de búsqueda se ejecute correctamente a lo largo del tiempo. Para evitar este problema, realizar compilaciones completas del índice de búsqueda cuando sea posible garantiza que el índice de búsqueda funcione bien con el tiempo.

Cuando Lucene recibe una solicitud de supresión, no suprime las entradas del índice, sino que las marca para supresión y añade registros actualizados al final del índice. Esto hace que el catálogo se propague de manera desigual entre los archivos de datos de segmento diferentes del índice de búsqueda y puede dar como resultado un aumento de los tiempos de respuesta de búsqueda. Si tiene un servidor de indexación dedicado, considere la posibilidad de planificar una creación de índice de búsqueda completa periódica. Haga que esta cree una tarea de fondo que se ejecute una vez al mes, para que las entradas suprimidas se vacíen y para optimizar los datos.

Servidor de indexación

Tenga en cuenta los siguientes factores al ajustar el servidor de indexación:

El preprocesador de construcción de índice está utilizando ahora VARCHAR como tipo de campo en lugar de CLOB

El tipo de datos de varias columnas de la tabla TI_ATTR se han cambiado de CLOB. Las seis columnas se definen ahora como varchar(32672) en DB2 y varchar2(32767) para Oracle en el archivo de configuración wc-dataimpoart-preprocess-attribute.xml. Se ha realizado el mismo cambio en la columna ATTRIBUTES de TI_ADATTR. Este cambio reduce el tiempo de preprocesamiento de estas dos tablas.

Este cambio requiere que los usuarios de Oracle habiliten la característica "Tipos de datos ampliados" que se describe en https://oracle-base.com/articles/12c/extended-data-types-12cR1. Si está migrando desde una versión anterior, asegúrese de descartar todas las tablas temporales antes de continuar.

Note: También debe ejecutar la instrucción en negrita en este ejemplo, o la base de datos Oracle no volverá a estar en línea después de un reinicio. Solo necesita ejecutar esta instrucción una vez.

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

Hay disponible un archivo de configuración de x-data-config.xml que consolida los parámetros que activan el preproceso de CLOB. Para utilizar CLOB en el preproceso, elimine el comentario de las secciones relevantes.

• x-data-config.xml

El preprocesador CopyColumnsDataPreProcessor puede reducir el tiempo de proceso de la tabla temporal en 50 %

El preprocesador utiliza la sintaxis SQL para eliminar la comunicación innecesaria de ida y vuelta entre Java y la base de datos. Esta sintaxis puede tener el formato: INSERT INTO <one table> SELECT FROM <another table>.

Para habilitar el preprocesador, copie y utilice los archivos de XML que se proporcionan.

• Para habilitar el preprocesador para la canalización CI/CD, empiece copiando los archivos XML dentro de la carpeta de ejemplos de entorno de desarrollo (kit de herramientas). Copie los archivos de XML del directorio samples/dataimport/copy_columns_data_preprocessor dentro del entorno de desarrollo en el directorio \WC\xml\search\dataImport para la canalización CI/CD.
  Note: En 9.0.1.1, la carpeta samples/dataimport/copy_columns_data_preprocessor está en desuso. Todos los archivos de XML correspondientes tienen una copia en la carpeta \WC\xml\search\dataImport\v3\database\CatalogEntry (donde database es db2 | oracle). El archivo tiene una extensión .copycolumns en el kit de herramientas. También están disponibles en /profile/installedApps/localhost/ts.ear/xml/search/dataImport/v3/database/CatalogEntry en el tiempo de ejecución de los contenedores Docker del servidor de programa de utilidad y transacción.
• Si desea una prueba rápida del preprocesador, copie los archivos XML del contenedor de programa de utilidad del Docker en el directorio /profile/installedApps/localhost/ts.ear/xml/search/dataImport del contenedor del Docker del servidor de transacciones. Puede completar este procedimiento para probar los resultados del preprocesador en la canalización CI/CD o dentro de un entorno de desarrollo.

La tabla siguiente lista los archivos de XML que utilizan el preprocesador CopyColumnsDataPreProcessor y la tabla temporal o las tablas que cada archivo puede optimizar.

Archivo XML	Tabla temporal
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: Antes de crear un índice, asegúrese de eliminar todas las tablas temporales.

Asegúrese de que tiene habilitado el rastreo. Ejecute el índice como de costumbre y utilice Trace para determinar qué mejoras de rendimiento se han producido.

CopyColumnsDataPreProcessor puede basarse en gran medida en el cálculo de la base de datos. Cuando se produce el preproceso, es posible que encuentre problemas con el proceso y vea el error "SQLCODE=-964,". Este error puede producirse cuando no hay suficiente espacio de registro para el preprocesador. Puede ejecutar sentencias SQL en la base de datos para aumentar el espacio de registro.

El tamaño del registro de transacciones en la base de datos DB2 está controlado por LOGFILSIZ y LOGPRIMARY+LOGSECOND. Las siguientes sentencias SQL proporcionan un ejemplo de cómo aumentar el espacio de registro a 4 KB*40000*(20+160)=28,8 GB:

 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

En HCL Commerce versión 9.0.1.3, CopyColumnsDataPreProcessor se utiliza de forma predeterminada para las tablas aplicables en xml/search/dataImport/v3/db2/CatalogEntry.

Note: Las tablas de los directorios antiguos (DB2 y Oracle) todavía utilizan StaticAttributeDataPreProcessor.

El registro de transacciones está inhabilitado de forma predeterminada para CopyColumnsDataPreProcessor. El ejemplo siguiente XML fragmento de código define cómo inhabilitar el registro de transacciones para 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> 

Para habilitar el registro de transacciones para CopyColumnsDataPreProcessor específicos, solo tiene que eliminar la propiedad no_logging_sql de la configuración. En este ejemplo, la propiedad no_logging_sql se ha eliminado:

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

CatalogHierarchyDataPreProcessor puede mejorar la velocidad de proceso cuando se especifica el parámetro fetchSize.

En HCL Commerce versión 9.0.0.6, CatalogHierarchyDataPreProcessor se actualiza para mejorar el rendimiento. Este preprocesador, que está habilitado de forma predeterminada, se utiliza para inyectar datos procesados en la tabla temporal TI_APGROUP. TI_APGROUP resulta ineficaz en números de catálogo de ventas grandes porque itera una estructura de datos interna y emite una consulta en cada iteración. Al especificar el parámetro fetchsize , puede mejorar la velocidad de proceso del preprocesador hasta el 50 %. La opción fetchsize es un proceso selección de lote que utiliza WHERE catentry_id en cualquier cláusula (?.?…?).

Los valores predeterminados de fetchSize y batchSize del preprocesador son cada 500. fetchSize no puede ser mayor que 32767 para Db2 o 1000 para Oracle.

Por ejemplo:

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

La consulta para la tabla temporal TI_ADATTR se ha cambiado en la versión 9.0.0.6+

Durante la creación del índice, casi todas las llamadas rtrim() y cast() se han eliminado de la consulta para la tabla temporal TI_ADATTR. Estas llamadas eran redundantes para las creaciones de índice ordinarias. La eliminación de estas llamadas mejora el tiempo de respuesta de esta consulta en bases de datos DB2 y mejora el escalado para un gran número de entradas de catálogo. El cambio para esta consulta está habilitado de forma predeterminada al actualizar a la versión 9.0.0.6+.

Memoria caché de búsqueda para el servidor de indexación

Normalmente se inhabilitan todas las memorias caché de Solr en el servidor de indexación.

Ajuste del tamaño de almacenamiento intermedio de índice y acciones de compromiso durante la importación de datos (buildindex)

Puede ajustar el archivo solrconfig.xml para asignar memoria suficiente para el almacenamiento intermedio de índice y evitar las acciones de compromiso cuando está creando el índice. Cuando el almacenamiento intermedio RAM para actualizaciones de índice está lleno, Solr realiza acciones de compromiso que persisten los datos en discos. Cuando se producen estas acciones de compromiso, Solr tiene un bloqueo exclusivo global en toda la JVM. Este bloqueo impide que otros subprocesos realicen operaciones de actualización, incluso cuando el subproceso está trabajando en registros o archivos diferentes. Este bloqueo puede aumentar la cantidad de tiempo que se necesita para construir el índice. Al aumentar el tamaño del almacenamiento intermedio RAM, e inhabilitar el desencadenante de compromiso, puede reducir las posibilidades de este bloqueo. Puede ajustar los parámetros de Solr para la temporización de compromisos y el tamaño de almacenamiento intermedio en el archivo solrconfig.xml:

• Asigne más memoria para el almacenamiento intermedio de índice cambiando el valor del parámetro ramBufferSizeMB. 2048 MB es el tamaño máximo de memoria que puede asignar:

  <ramBufferSizeMB>2048</ramBufferSizeMB>

• Inhabilite el desencadenante de compromiso automático del lado del servidor para reducir también la aparición de acciones de compromiso, comentando el desencadenante autoCommit:

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

Configuración del tamaño de paginación y de almacenamiento dinámico de base de datos

Asegúrese de que el tamaño de paginación y memoria esté configurado de acuerdo con el tamaño de los datos de catálogo o si el entorno contiene varios índices para diferentes idiomas. Por ejemplo, si tiene problemas con el acceso o la creación de grandes cantidades de datos de índice:

1. Aumente el tamaño de paginación predeterminado para el sistema operativo. Por ejemplo, 3 GB. En los casos en que el sistema operativo requiera un tamaño de paginación superior, la adición de más memoria al sistema también ayuda a resolver los problemas.
2. Aumente el tamaño del almacenamiento dinámico de base de datos predeterminado a un valor más alto. Por ejemplo, aumente el tamaño de almacenamiento dinámico de DB2 a 8192.
3. Aumente el límite de descriptores de archivo a un valor más alto. Por ejemplo: ulimit -n 8192.

Configuración del tamaño de almacenamiento dinámico

Asegúrese de que el tamaño del almacenamiento dinámico de HCL Commerce Search esté configurado de acuerdo con el tamaño de los datos de catálogo o si el entorno contiene varios índices para diferentes idiomas. Por ejemplo, si está teniendo problemas de acceso a grandes cantidades de datos de índice, aumente el valor de heapsize predeterminado a un valor más alto, como 1280. Para obtener más información, consulte Configurar el tamaño de almacenamiento dinámico de JVM en WebSphere Liberty.

Important:

• No supere 28 GB del tamaño de almacenamiento dinámico por JVM, incluso cuando se utiliza un entorno de 64 bits. En una JVM de 64 bits, hay una característica de optimización de referencia comprimida de la dirección que puede inhabilitarse si el espacio de almacenamiento dinámico es superior a 28 GB. Si está inhabilitado, puede haber hasta un 30% de degradación de rendimiento global.

Configuración de tamaño de agrupación compartida

Asegúrese de que SHARED_POOL_SIZE se ha configurado de acuerdo con el entorno. El aumento del tamaño de la agrupación compartida puede mejorar el rendimiento del proceso de creación de índice.

Por ejemplo:

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

Ejecución de varias hebras de expresiones de consulta SQL

Considere la posibilidad de utilizar varias hebras en DB2 para permitir un mayor rendimiento cuando se preprocesa el índice de búsqueda.

Para ello, establezca INTRA_PARALLEL=YES en la configuración de DB2 dBm. En el lado del cliente de BD, actualice la propiedad de origen de datos de currentDegree a ANY. El programa de utilidad de proceso paralelo está en di-parallel-process.properties. Una sentencia de configuración de ejemplo es Database.jdbcURL=jdbc:db2://db:50000/mall:currentDegree=ANY. Para obtener más información, consulte Common IBM Data Server Driver for JDBC and SQLJ properties for Db2 servers.

Servidor de tiempo de ejecución de búsqueda

Tenga en cuenta los siguientes factores al ajustar el servidor de tiempo de ejecución de búsqueda:

Almacenamiento en memoria caché

Memoria caché de búsqueda para los servidores subordinados de producción de tiempo de ejecución

La configuración de inicio incluida en el archivo solrconfig.xml de CatalogEntry solo está diseñada para un entorno de desarrollo a pequeña escala, como HCL Commerce Developer.

Cuando vuelva a implementar esta configuración de índice en un sistema de mayor escala, como un sistema de ensayo o de producción, personalice al menos los siguientes parámetros de memoria caché:

• queryResultWindowSize
• queryResultMaxDocsCached
• queryResultCache
• filterCache (Necesario en el índice de producto cuando existe un índice de extensión como Inventario)
• documentCache (Necesario en el índice de producto cuando existe un índice de extensión como Inventario)

El ejemplo siguiente muestra cómo definir tamaños de memoria caché para el índice de entrada de catálogo y su correspondiente espacio de almacenamiento dinámico de memoria que se necesita en la JVM:

Tamaño de catálogo de ejemplo:

Tamaño de catálogo

1,8 millones de entradas.

Total de atributos

2000

Total de categorías

10000

Cada producto contiene

Veinte atributos.

Promedio de tamaño de cada entrada de catálogo

10 KB.

Cálculo de ejemplo:

queryResultWindowSize

Tamaño de cada página de resultados de búsqueda en el escaparate, por ejemplo 12 elementos por página. Esto incluye dos páginas de captación previa.

Esta acción da como resultado un valor queryResultWindowSize de 36 (3 x 12).

queryResultMaxDocsCached

Para obtener un rendimiento óptimo, establezca este valor para que sea el mismo que el valor de queryResultWindowSize.

queryResultCache

El tamaño de cada queryResultCache es 4 bytes por referencia de docId (int) x queryResultWindowSize, para un valor de 144 bytes.

Asigne ranuras de memoria caché de 10 M para almacenar en caché las tres primeras páginas de la consulta principal.

Esta acción produce un tamaño de queryResultCache necesario total de 1,44 GB (144 B x 10000000).

filterCache

Supongamos que el tamaño de resultado de búsqueda de promedio es del 5% del tamaño de catálogo completo de 1,8 M, o 90.000.

El tamaño de cada filterCache es de 4 bytes por referencia de docId (int) x número aleatorio de búsquedas con resultados de 90.000, lo que es igual a 360 KB.

Asigne 5000 entradas para filterCache.

El tamaño total necesario para filterCache produce un valor de 1,8 GB (360 KB x 5000).

Note: El filterCache es necesario en el índice de producto cuando existe un índice de extensión como Inventario, para que el componente de consulta funcione correctamente.

documentCache

Supongamos que el tamaño medio de cada documento de entrada de catálogo es de 10 KB.

Asigne el 5% del catálogo entero a la memoria caché o 100000 entradas para documentCache.

El tamaño total necesario para documentCache produce un valor de 1,0 GB (10 KB x 100000).

Note:

• Establezca el tamaño de documentCache como mínimo en el tamaño máximo previsto de un resultado de búsqueda.
• El documentCache es necesario en el índice de producto cuando existe un índice de extensión como Inventario, para que el componente de consulta funcione correctamente.

Como resultado, el tamaño de almacenamiento dinámico de JVM estimado que se necesita para cada núcleo de entrada de catálogo es 4,3 GB (1,44 GB + 1,8 GB + 1,0 GB).

Gestión de los tamaños de memoria caché para ajustarlos a la memoria de la JVM

Asegúrese de configurar el valor fieldValueCache del núcleo de índice de entradas de catálogo en el archivo solrconfig.xml. Esta configuración puede evitar problemas de memoria insuficiente al limitar su tamaño para ajustarlo a la memoria de la JVM.

El tamaño del conjunto de memoria caché depende de la cantidad de campos de faceta y del tamaño del catálogo. El tamaño de la entrada de memoria caché se puede calcular aproximadamente mediante la cantidad de entradas de catálogo en el núcleo de índice, que luego se multiplica por 4 bytes. Es decir, la posible cantidad de entradas de memoria caché es igual a la cantidad de posibles facetas.

Por ejemplo, en el archivo solrconfig.xml:

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

Note: La implementación de almacenamiento en memoria caché de solr.FastLRUCache recomendada no tiene un límite estricto para su tamaño. Es útil para las memorias caché que tienen una proporción de coincidencias alta, pero que pueden superar significativamente el valor de tamaño que se ha establecido. Si está utilizando solr.FastLRUCache, supervise la utilización del almacenamiento dinámico durante los periodos de máxima actividad. Si el almacenamiento en memoria caché excede excesivamente este límite, considere cambiar la clase fieldValueCache por solr.LRUCache para evitar problemas de rendimiento o una condición de agotamiento de memoria.

Para obtener más información, consulte https://https://lucene.apache.org/solr/guide/7_3/query-settings-in-solrconfig.html/solr/guide/6_6/query-settings-in-solrconfig.html.

Ajuste de la memoria caché de datos de relevancia de búsqueda

Asegúrese de ajustar la memoria caché de datos de relevancia de búsqueda para el tamaño del catálogo.

Los datos de relevancia se almacenan en la siguiente instancia de memoria caché:

• services/cache/SearchNavigationDistributedMapCache

Cada entrada está en un rango de 8 a 10 KB, conteniendo de 10 a 20 campos de relevancia. La instancia de memoria caché también contiene otros tipos de entradas de memoria caché. La base de datos se utiliza para cada visita de página cuando la instancia de memoria caché está llena, lo que reduce el rendimiento.

Ajuste de la memoria caché de datos de búsqueda para la navegación por facetas

El código de servidor de HCL Commerce Search utiliza el recurso de memoria caché dinámica de WebSphere para realizar el almacenamiento en memoria caché de los resultados de consulta de base de datos. Similar a la memoria caché de datos utilizada por el servidor de HCL Commerce principal, este código de almacenamiento en memoria caché se denomina memoria caché de datos de servidor de HCL Commerce Search.

Ajuste del espacio de almacenamiento dinámico cuando la visualización de productos de búsqueda está habilitada

Por ejemplo, si utiliza la estimación 15MB/categoría, la secuenciación manual de 200 categorías con un tamaño de catálogo de 100k puede utilizar 3GB de memoria. La secuenciación manual de las mismas 200 categorías pueden utilizar 6 GB cuando el tamaño de catálogo es 1,1 millón. Por lo tanto, el espacio de almacenamiento dinámico asignado por categoría debe ajustarse de acuerdo con el tamaño de catálogo.

Rendimiento de faceta

Índice de extensión

Opciones de configuración

Configuración de la búsqueda

Asegúrese de estar familiarizado con los diversos parámetros de configuración de Solr, Solr Wiki: solrconfig.xml. La documentación contiene información para las personalizaciones de configuración típicas que pueden aumentar potencialmente el rendimiento del servidor de búsqueda. Por ejemplo, si la tienda contiene un gran número de categorías o contratos, o si el servidor de búsqueda está recibiendo errores de Too many boolean clauses, aumente el valor predeterminado para maxBooleanClauses.

Indexación de cambios y otras consideraciones

Recopilación de basura

La política de colector de basura predeterminado para la JVM de WebSphere Commerce es el recopilador de basura simultáneo generacional.HCL Commerce En general, no es necesario cambiar esta política de recopilador de información no válida. Normalmente, no es necesario cambiar esta política de recopilador de basura.

Puede activar el recopilador de basura simultáneo generacional para la JVM de HCL Commerce Search utilizando la opción de línea de mandatos -Xgcpolicy:gencon.-Xgcpolicy:gencon

Note: La utilización de una política de recogida de basura distinta del recopilador de basura simultáneo generacional puede provocar situaciones donde se incrementen los tiempos de proceso de solicitud y la utilización de CPU alta.

Para obtener más información, consulte las Políticas de recopilaciones de basura.

Corrección ortográfica

Puede experimentar un impacto en el rendimiento cuando se habilita la corrección ortográfica para los términos de HCL Commerce Search.

Es posible que vea mejoras de rendimiento en el proceso de transacciones si se omite la corrección ortográfica cuando sea necesario, o cuando los usuarios buscan productos con alteraciones temporales de catálogo.

Por ejemplo, un término de búsqueda que se somete en un idioma distinto al del escaparate requiere recursos para la corrección ortográfica. Sin embargo, los nombres de productos con alteraciones temporales de catálogo ya son conocidos y no requieren recursos para la corrección ortográfica.

Este componente de corrector ortográfico utiliza datos directamente desde el índice CatalogEntry, en lugar de depender de un índice autónomo independiente.DirectSolrSpellChecker

Mejora del rendimiento de vista previa de la tienda para cambios de búsqueda

Para mejorar el rendimiento cuando obtiene la vista previa de los cambios de búsqueda, puede omitir la indexación de contenido no estructurado cuando los usuarios de negocio inician la vista previa de tienda:

En el archivo wc-component.xml, establezca la propiedad IndexUnstructured en false.

Para obtener más información, consulte Cambio de propiedades en el archivo de configuración de HCL Commerce (wc-component.xml).

Supervisión del rendimiento