Crear mejores prácticas de rendimiento y capacidad de índice para clientes de alto volumen

Una implementación de alto volumen HCL Commerce puede incluir un gran volumen de catálogo, un gran número de idiomas y una cantidad limitada de tiempo para crear el índice de búsqueda. Al realizar una planificación de capacidad cuidadosa y seguir los métodos recomendados de rendimiento, puede optimizar el rendimiento y la capacidad para HCL Commerce versión 9.0.1.3 y superior.

Mejores prácticas de planificación de capacidad

Para los usuarios de alto volumen de HCL Commerce que desean crear el índice de búsqueda en un periodo de tiempo más corto, debe tener suficientes recursos de hardware. Los recursos a tener en cuenta incluyen, pero no están limitados a, CPU, memoria, almacenamiento (entrada/salida de disco), ancho de banda de red.
Importante: El procedimiento de planificación y los números de muestra que se describen en este tema son para su referencia. Debe adaptar el procedimiento para su entorno específico. El rendimiento de HCL Commerce depende de la carga de trabajo, la estructura de datos y las opciones de ajuste específicas que implemente. Realice pruebas de rendimiento para validar la implementación en su entorno.

Recursos de CPU

La creación del índice de búsqueda es un procedimiento que utiliza un cálculo de CPU intensivo. Para crear un índice con muchos idiomas en un periodo de tiempo corto, debe utilizar el proceso paralelo y la fragmentación. La creación del índice de búsqueda de HCL Commerce soporta el proceso paralelo y la fragmentación. Para obtener más información, consulte https://help.hcltechsw.com/commerce/9.0.0/search/concepts/csdsearchparallel.html.

CPU recursos es el primer factor que se debe tener en cuenta cuando se tiene previsto optimizar el rendimiento, incluidos los siguientes métodos recomendados.

  1. Determinar el número de fragmento

    En general, el proceso de diferentes idiomas se realiza en paralelo. Con suficientes recursos de hardware, la duración del índice de creación total para varios idiomas es la misma que la creación de un idioma. Cuando se utiliza la fragmentación, todo el procedimiento de índice de compilación se divide en tres etapas: preproceso, indexación y fusión. La duración del preproceso y la fusión es aproximadamente igual a la duración de la indexación, y la velocidad de indexación es de 1 millón a 1,5 millones documentos por hora. Este ejemplo utiliza una estimación conservadora de 500 000 documentos por hora para calcular la duración total del índice de compilación.

    Para muchas implementaciones de HCL Commerce, hay mucho más documentos de índice de entrada de catálogo que documentos de índice de grupo de catálogo. Este ejemplo considera solo la creación del índice de entrada de catálogo porque la compilación de índice paralelo solo da soporte al núcleo de entrada de catálogo.

    En este ejemplo, el catálogo de creación de índice contiene 6 millones entradas de catálogo (incluidos productos, números de código de artículo, paquetes compuestos y otras entradas) y el periodo de tiempo objetivo para que la compilación se complete es de 3 horas. En este escenario, el número de fragmento necesario es 6/3/0,5, que es igual a cuatro fragmentos. Para acortar el tiempo de compilación a 1,5 horas, debe aumentar el número de fragmento a 8 (6/1,5/0,5 = 8).

  2. Determinar el número de hebras de trabajo y el número de CPU virtual (VCPU)
    En este ejemplo, HCL Commerce contiene 6 millones entradas de catálogo, un rango de tiempo de 3 horas para crear el índice y 10 idiomas a compilar. En este escenario, necesitará 40 hebras de trabajo (4 multiplicado por 10) para realizar el proceso paralelo para la indexación, que es la parte más intensiva del procedimiento completo.
    Nota: El preproceso requiere más hebras de trabajo y la fusión necesita menos hebras de trabajo.

    También necesita asignar 1-2 VCPU por cada hebra de trabajo. Para obtener más información, consulte https://help.hcltechsw.com/commerce/9.0.0/admin/concepts/cpmdockertune.html. Si asigna dos VCPU por hebra de trabajo, el proceso es más rápido que asignar 1 VCPU por hebra de trabajo.

    La indexación se realiza en el servidor de búsqueda Docker, por lo que en este ejemplo asignará 40-80 VCPU en total para los Docker del servidor de búsqueda. Si hay ocho acopladores de servidor de búsqueda, cada Docker se asigna 5-10 VCPU.

    A continuación, puede determinar la asignación de recursos CPU para el servidor de base de datos y el programa de utilidad Docker, que es donde se ejecuta el preproceso. El método recomendado es asignar el 50-100 por ciento del VCPU de los acopladores del servidor de búsqueda para el servidor de bases de datos (que equivale a 40-80 VCPU en este escenario). Además, se recomienda asignar 25-50 por ciento VCPU de los acopladores de servidor de búsqueda para el programa de utilidad Docker (que equivale a 20-40 VCPU para este escenario).

  3. Considerar procesar por lotes la creación de índice

    Si tiene menos recursos de hardware disponibles y un marco de tiempo más relajado, o si el número total de idiomas es demasiado grande para que se procese en paralelo, puede considerar la posibilidad de procesar por lotes la creación de índice.

    En el escenario de ejemplo (en el que hay 6 millones entradas de catálogo y 10 idiomas), supongamos que el periodo de tiempo de índice de compilación es de 6 horas en lugar de 3 horas. En este caso, puede dividir todo el procedimiento de creación de índice en dos lotes, con cada lote que contenga cinco idiomas. La división del procedimiento en estos lotes reduce el recurso CPU a la mitad de lo que se necesitaba originalmente. Para procesar por lotes la compilación, divida el archivo de propiedades de preproceso paralelo en dos archivos separados (cada uno contiene cinco idiomas) y escriba un archivo de proceso por lotes para bifurcar el procedimiento de índice de compilación uno por uno con el archivo de propiedades diferente.

Recursos de almacenamiento

Los datos de entrada que se utilizan para crear el índice se almacenan en el servidor de bases de datos como un archivo de información, mientras que los datos de salida del índice se almacenan en el servidor de búsqueda como un archivo de índice. Tanto los archivos de entrada como de salida se almacenan en el sistema de archivos físico y, cuando hay una gran cantidad de datos para crear, la e/s de disco es intensiva. Este acceso de e/s durante la creación del índice es el acceso aleatorio, y se recomienda utilizar el almacenamiento de disco de estado sólido (SSD) en lugar del almacenamiento de la unidad de disco duro (HDD) para los servidores de base de datos y de búsqueda. El almacenamiento SSD proporciona un mayor ancho de banda de e/s por segundo (IOPS).

Además del ancho de banda de IOPS, también es importante el ancho de banda de lectura y escritura total (MB por segundo). Para el servidor de bases de datos, la mayoría de las e/s de disco se producen durante el preproceso. Para el servidor de búsqueda, la mayoría de las e/s de disco se producen para la fusión. Cada procedimiento debe leer una gran cantidad de datos del disco y escribir una gran cantidad de datos en un breve periodo de tiempo.

Los IOPS reales y el ancho de banda de lectura/grabación se determinan por el tamaño medio de los datos de cada código de artículo (incluidos los bits de identificador, la longitud del nombre de atributo y valor, la longitud de la descripción, etc.). Este escenario de ejemplo proporciona un número solo como referencia; el cálculo de la implementación debe basarse en los valores.

Para la tienda de ejemplo HCL Commerce, el tamaño medio del archivo de índice para cada entrada de catálogo es de 5 KB antes de fusionar y 3 KB después de la fusión. Para el cliente de ejemplo con 6 millones entradas de catálogo, 10 idiomas y un rango de tiempo de 3 horas, el procedimiento de fusión cuenta las cuentas aproximadamente un cuarto de todo el procedimiento. En este escenario, el procedimiento de fusión tarda aproximadamente 45 minutos (2700 segundos). El procedimiento de fusión debe leer 300 GB (5 KB multiplicados por 6 millones entradas de catálogo multiplicadas por 10 idiomas) del disco y grabar 180 GB (3 KB multiplicados por 6 millones multiplicado por 10 idiomas) en disco en 2700 segundos. La e/s de disco no se distribuye uniformemente durante el procedimiento de fusión. Por lo tanto, el ancho de banda de e/s asignado debe ser y menor dos veces el número pronosticado.

Además, el ancho de banda de e/s que se asigna para el servidor de base de datos debe ser varias veces mayor que el servidor de búsqueda. Esta asignación se debe al gran número de tablas temporales y registros de transacciones.
Importante: El número real se ve afectado por el ajuste de rendimiento.

Recursos de memoria

Incluso si utiliza el almacenamiento SSD de alta velocidad, la operación de e/s de disco es todavía mucho más lenta que si utiliza la operación en memoria. Por lo tanto, la mejor práctica para los recursos de memoria para los servidores de base de datos y de búsqueda es que más es mejor. Se consigue un mejor rendimiento si el servidor de bases de datos tiene memoria para contener todo el archivo de base de datos en la memoria y el servidor de búsqueda puede contener todo el archivo de índice en la memoria. En general, un número inferior de recursos de memoria provoca más operaciones de e/s de disco y ralentiza el procedimiento de índice de compilación completo.

Recursos de red

Durante el procedimiento de creación de índice, la gran cantidad de datos que se leen y se escriben en el disco también se transfieren a través de la red (entre el servidor de bases de datos y el programa de utilidad Docker, y entre el servidor de bases de datos y el servidor de búsqueda).

Para un cliente de alto volumen, se necesita Gigabit Ethernet como conexión de red entre el servidor de bases de datos y el programa de utilidad Docker, y entre el servidor de bases de datos y el servidor de búsqueda. Si tiene requisitos más desafiantes, se recomienda utilizar varias líneas de conexión o diez Gigabit Ethernet para evitar que se produzcan cuellos de botella durante las transferencias de red.

Ajuste del rendimiento

Utilice siempre la última versión de HCL Commerce para utilizar las mejoras de rendimiento más recientes en el código de producto.

Además, siga estas recomendaciones generales para lograr el rendimiento óptimo para la creación de índices de gran volumen.

Importante: Estas recomendaciones de métodos recomendados se basan en los resultados de la prueba del entorno de laboratorio. Por lo tanto, el ajuste real debe basarse en las pruebas de rendimiento de su entorno.
  • Preproceso con el programa de utilidad Docker
    • Habilite el preproceso de hebra múltiple estableciendo Global.preprocessing-multithread=true en di-parallel-process.properties.
    • Habilite el preprocesamiento de varias hebras para todos los idiomas definiendo Global.preprocessing-locale=en_US,ja_JP,de_DE (configuraciones regiones separadas por comas).
      Importante: Si este parámetro se establece como Global.preprocessing-locale=all, los idiomas se procesarán secuencialmente.
    • Adapte la configuración de preproceso XML archivos para controlar el número de hebras de trabajo paralelas. Para obtener más información, consulte la sección control del número de hebras de trabajo de preproceso.
    • Utilice CopyColumnsDataPreProcessor para la mayoría de las tablas. CopyColumnsDataPreProcessor es el valor predeterminado para HCL Commerce versión 9.0.1.3 y posteriores.
    • Para Db2®, inhabilite el registro de transacciones para CopyColumnsDataPreProcessor.
    • Aumente el número de fetchSize y batchSize para los DataPreProcessor no CopyColumns.
  • Indexación con el servidor de búsqueda Docker
    • Aumente batchSize (solr.dih.batchSize), que se define como una opción JVM global o como un parámetro a nivel de núcleo en la tabla SRCHCONFEXT de la base de datos.
  • Servidor de bases de datos
    • Para Db2®, habilite el paralelismo dentro de la partición para estableciendo INTRA_PARALLEL=YES en dbm cfg.

Control del número de hebras de trabajo de preproceso

Según los resultados de prueba del entorno de laboratorio, el servidor de bases de datos no es lineal-escalable para el procesamiento paralelo durante el preproceso. Después de que se produzca el punto de saturación, si aumenta el número de hebras de trabajo paralelas puede causar un impacto negativo en el rendimiento. Cuando habilita el paralelismo interno de la partición en Db2®, hay varias hebras de trabajo en el servidor Db2® para cada hebra de trabajo de preproceso. Por lo tanto, es importante controlar el número de hebras de trabajo de preproceso para conseguir un rendimiento de índice de compilación óptimo.

Cuando el preproceso de hebra múltiple está inhabilitado, hay un preproceso que funciona hebra por fragmento y por idioma. Pero, cuando el preproceso de hebra múltiple está habilitado, hay varios hebras de trabajo de preproceso por fragmento y por idioma. El comportamiento del código de producto HCL Commerce es crear una hebra de trabajo para cada XML de configuración de preproceso (por ejemplo wc-dataimport-preprocess-attribute.xml). Los archivos de XML de preproceso de ejemplo se organizan por relación de tabla en lugar de por consideración de rendimiento. Puede dividir o fusionar archivos de XML diferentes basándose en las consideraciones de rendimiento.

Desde la versión 9.0.1.2+, el preproceso se divide en dos fases. La primera fase es para procesar tablas independientes del idioma (que solo se produce una vez). La segunda fase es para procesar tablas dependientes del idioma, en las que todos los idiomas se procesan en paralelo.

Para la primera fase, el número total de hebra de trabajo es igual al XML número multiplicado por el número de fragmento. Para la segunda fase, el número total de hebra de trabajo es igual al XML número multiplicado por el número de fragmento multiplicado por el número de idioma. Cuando hay muchos idiomas para el proceso paralelo, el número de hebra de trabajo puede ser diferente entre las dos fases.

En general, puede dividir los archivos de XML de tabla independientes del idioma y fusionar los archivos XML de tabla dependientes del idioma para equilibrar el número de hebra de trabajo de las dos fases. Por ejemplo, todos los archivos XML de tabla dependientes del idioma se fusionan en un XML. De este modo, el número total de hebra de trabajo en la segunda fase es igual al número de fragmento multiplicado por el número de idioma.