El SDK de Google Cloud Search contiene varios parámetros de configuración proporcionados por Google que son usados por todos los conectores. Conocer cómo establecer esta configuración puede optimizar la indexación de datos de forma significativa. En esta guía, se muestran varios problemas que pueden surgir durante la indexación y la configuración que se usa para resolverlos.
La capacidad de procesamiento de indexación es baja para FullTraversalConnector
En la siguiente tabla, se muestra la configuración para mejorar la capacidad de procesamiento de un FullTraversalConnector:
| Configuración | Descripción | Valor predeterminado | Cambio de configuración para intentar |
|---|---|---|---|
traverse.partitionSize |
La cantidad de ApiOperation() que se procesará por lotes antes de recuperar APIOperation() adicionales. El SDK espera a que se procese la partición actual antes de recuperar elementos adicionales. Esta configuración depende de la cantidad de memoria disponible. Los tamaños de partición más pequeños, como 50 o 100, requieren menos memoria, pero más espera por parte del SDK. |
50 | Si tienes mucha memoria disponible, intenta aumentar partitionSize a 1,000 o más. |
batch.batchSize |
La cantidad de solicitudes agrupadas. Al final de la partición, el SDK espera a que se procesen todas las solicitudes por lotes desde la partición. Los lotes más grandes requieren una espera más larga. | 10 | Intenta reducir el tamaño del lote. |
batch.maxActiveBatches |
Cantidad de lotes de ejecución simultánea permitidos. | 20 | Si reduces batchSize, debes aumentar maxActiveBatches de acuerdo con esta fórmula: maxActiveBatches = (partitionSize / batchSize) + 50. Por ejemplo, si tu partititionSize es 1,000 y tu batchSize es 5, tu maxActiveBatches debe ser 250. Los 50 adicionales son un búfer para reintentar las solicitudes. Este aumento permite que el conector agrupe por lotes todas las solicitudes sin bloqueos. |
traverse.threadPoolSize |
Cantidad de subprocesos que crea el conector para permitir el procesamiento en paralelo. Un solo iterador recupera las operaciones (por lo general, objetos RepositoryDoc) de manera secuencial, pero las llamadas a la API se procesan en paralelo mediante una cantidad de subprocesos igual a threadPoolSize. Cada subproceso procesa un elemento a la vez. El valor predeterminado de 50 procesaría un máximo de solo 50 elementos de forma simultánea y tardaría unos 4 segundos para procesar un elemento individual (incluida la solicitud de indexación). |
50 | Intenta aumentar threadPoolSize por un múltiplo de 10. |
Por último, considera usar el método setRequestMode() para cambiar el modo de solicitud de la API (ASYNCHRONOUS o SYNCHRONOUS).
Para obtener más información sobre los parámetros del archivo de configuración, consulta los parámetros de configuración que proporciona Google.
La capacidad de procesamiento de indexación es baja para ListTraversalConnector
De forma predeterminada, un conector que implementa el ListTraversalConnnector usa un único desviador para indexar los elementos. Para aumentar la capacidad de procesamiento de indexación, puedes crear varios desviadores, cada uno con su propia configuración centrada en estados de elementos específicos (NEW_ITEM, MODIFIED, etcétera). En la siguiente tabla, se muestra la configuración para mejorar la capacidad de procesamiento:
| Configuración | Descripción | Valor predeterminado | Cambio de configuración para intentar |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Crea uno o más desviadores individuales en los que t1, t2, t3, ... es el nombre único de cada uno. Cada generador de recorrido con nombre tiene su propio conjunto de parámetros de configuración que se identifican con el nombre único del generador de recorrido, como traversers.t1.hostload y traversers.t2.hostload. | Un desviador | Usa esta configuración para agregar desviadores adicionales |
traversers.t1.hostload = n | Identifica la cantidad de subprocesos, n, que se usarán para indexar elementos de forma simultánea. | 5 | Experimenta y ajusta n según la cantidad de carga que deseas poner en tu repositorio. Comienza con valores de 10 o más. |
schedule.pollQueueIntervalSecs = s | Identifica la cantidad de segundos, s, que se esperarán antes de volver a realizar una consulta . El conector de contenido continúa con la consulta de elementos, siempre y cuando la API muestre los elementos en la respuesta de la consulta. Cuando la respuesta de la consulta está vacía, el conector espera s segundos antes de volver a intentarlo. Solo el ListingConnector usa esta configuración | 10 | Intenta bajar a 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Especifica los estados, status1, status2, …, de los elementos a indexar. Por ejemplo, si configuras status1 como NEW_ITEM y status2 como MODIFIED, se le indica al buscador t1 que solo indexe elementos con esos estados. | Un desviador verifica todos los estados | Experimenta con diferentes desviadores que consulten diferentes estados. |
Para obtener más información sobre los parámetros del archivo de configuración, consulta los parámetros de configuración que proporciona Google.
El SDK excede el tiempo de espera o se interrumpe mientras sube archivos grandes
Si experimentas un tiempo de espera del SDK o interrupciones mientras subes archivos grandes, especifica un tiempo de espera mayor con traverser.timeout=s (donde s = cantidad de segundos). Este valor identifica cuánto tiempo tienen los subprocesos de trabajador para procesar un elemento. El tiempo de espera predeterminado en el SDK es de 60 segundos para los subprocesos de recorrido. Además, si las solicitudes a la API individuales agotan el tiempo de espera, usa los siguientes métodos para aumentar los valores de tiempo de espera de la solicitud:
| Parámetro de tiempo de espera de la solicitud | Descripción | Valor predeterminado |
|---|---|---|
indexingService.connectTimeoutSeconds |
Tiempo de espera de conexión para indexar solicitudes a la API. | 120 segundos. |
indexingService.readTimeoutSeconds |
Tiempo de espera de lectura para indexar solicitudes a la API. | 120 segundos. |