El SDK de Google Cloud Search contiene varios parámetros de configuración proporcionados por Google que son usados por todos los conectores. Saber cómo ajustar esta configuración puede optimizar en gran medida la indexación de datos. En esta guía, se enumeran 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:
| Parámetro de configuración | Descripción | Predeterminada | Cambio de configuración para intentar |
|---|---|---|---|
traverse.partitionSize |
La cantidad de ApiOperation() que se procesará en 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 disminuyes batchSize, deberías aumentar maxActiveBatches de acuerdo con esta fórmula: maxActiveBatches = (partitionSize / batchSize) + 50. Por ejemplo, si la partititionSize es 1,000 y la batchSize es 5, el maxActiveBatches debería 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) en serie, pero las llamadas a la API se procesan en paralelo mediante una cantidad threadPoolSize de subprocesos. 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 a 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 solo 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 | Predeterminada | 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 desviador nombrado tiene su propio conjunto de parámetros de configuración, que se identifican con el nombre único del desviador, 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 en función de cuánta carga 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 encuesta 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 que se indexarán. Por ejemplo, configurar status1 en NEW_ITEM y status2 en MODIFIED le indica al desviador t1 que indexe solo los 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 interrupciones o tiempos de espera del SDK cuando 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 trabajo para procesar un elemento. El tiempo de espera predeterminado en el SDK es de 60 segundos para los subprocesos de desviador. Además, si experimentas que se agota el tiempo de espera de las solicitudes a la API individuales, usa los siguientes métodos para aumentar los valores del tiempo de espera de la solicitud:
| Parámetro de tiempo de espera de la solicitud | Descripción | Predeterminada |
|---|---|---|
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. |