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 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 | Predeterminado | Cambio de configuración para intentar |
|---|---|---|---|
traverse.partitionSize |
La cantidad de ApiOperation() que se procesarán 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 el valor de 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, deberías cambiar 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) en serie, pero las llamadas a la API se procesan en paralelo mediante una cantidad de subprocesos de 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 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 proporcionados por Google.
La capacidad de procesamiento de indexación es baja para ListTraversalConnector
De forma predeterminada, un conector que implementa ListTraversalConnnector usa un solo desviador para indexar tus 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 | 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 desviador con nombre tiene su propio conjunto de parámetros de configuración, que se identifican mediante 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 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 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, establecer status1 en NEW_ITEM y status2 en MODIFIED le indica al desviador 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 proporcionados por Google.
El SDK excede el tiempo de espera o se interrumpe mientras sube archivos grandes
Si experimentas un tiempo de espera del SDK o se interrumpen 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 trabajo para procesar un elemento. El tiempo de espera predeterminado en el SDK es de 60 segundos para los subprocesos de desvío. Además, si se agota el tiempo de espera de las solicitudes
a la API individuales, usa los siguientes métodos para aumentar los valores de tiempo de espera de las solicitudes:
| Parámetro de tiempo de espera de la solicitud | Descripción | 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. |