O SDK do Google Cloud Search contém vários parâmetros de configuração fornecidos pelo Google que são usados por todos os conectores. Saber como ajustar essas configurações pode simplificam bastante a indexação de dados. Este guia lista vários problemas que podem aparecer durante a indexação e as configurações usadas para resolvê-los.
A capacidade de indexação é baixa para o FullTraversalConnector
A tabela a seguir lista as definições de configuração para melhorar a capacidade de uma FullTraversalConnector:
| Configuração | Descrição | Padrão | Alteração na configuração para testar |
|---|---|---|---|
traverse.partitionSize |
O número de ApiOperation() a ser processado em lotes antes de buscar mais APIOperation(). O SDK aguarda o processamento da partição atual antes de buscar outros itens. Essa configuração depende da quantidade de memória disponível. Tamanhos de partição menores, como 50 ou 100, exigem menos memória, mas mais espera por causa do SDK. |
50 | Se você tiver muita memória disponível, tente aumentar partitionSize para 1.000 ou mais. |
batch.batchSize |
O número de solicitações em lote. No final do particionamento, o SDK aguarda o processamento de todas as solicitações em lote da partição. Lotes maiores requerem uma espera mais longa. | 10 | Tente diminuir o tamanho do lote. |
batch.maxActiveBatches |
Número de lotes de execução simultânea permitidos. | 20 | Se você diminuir batchSize, aumente o valor de maxActiveBatches de acordo com esta fórmula: maxActiveBatches = (partitionSize / batchSize) + 50. Por exemplo, se partititionSize for 1000 e batchSize for 5, maxActiveBatches vai ser 250. Os 50 a mais são um buffer para solicitações de nova tentativa. Esse aumento permite que o conector agrupe todas as solicitações sem bloqueio. |
traverse.threadPoolSize |
Número de linhas de execução que o conector cria para permitir o processamento paralelo. Um único iterador busca operações (normalmente objetos RepositoryDoc) em série, mas a API chama o processo em paralelo usando um número threadPoolSize de linhas de execução. Cada linha de execução processa um item de cada vez. O padrão 50 processa no máximo apenas 50 itens simultaneamente e leva aproximadamente 4 segundos para processar um item individual (incluindo a solicitação de indexação). |
50 | Tente aumentar threadPoolSize por um múltiplo de 10. |
Por fim, considere usar o método setRequestMode() para mudar o modo de solicitação da API (ASYNCHRONOUS ou SYNCHRONOUS).
Para mais informações sobre os parâmetros do arquivo de configuração, consulte Parâmetros de configuração fornecidos pelo Google.
A capacidade de indexação é baixa para ListTraversalConnector
Por padrão, um conector que implementa o ListTraversalConnnector usa um
um único atravessador para indexar seus itens. Para aumentar a capacidade de indexação, faça o seguinte:
criar vários atravessadores, cada um com a própria configuração, com foco em funções
status do item (NEW_ITEM, MODIFIED etc.). A tabela a seguir lista
de configuração para melhorar a capacidade de processamento:
| Configuração | Descrição | Padrão | Alteração na configuração para testar |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Cria um ou mais atravessadores individuais, em que t1, t2, t3, ... é o nome exclusivo de cada um. Cada atravessador nomeado tem seu próprio conjunto de configurações, que são identificadas usando o nome exclusivo do atravessador, como traversers.t1.hostload e traversers.t2.hostload. | Um atravessador | Use esta configuração para adicionar mais atravessadores. |
traversers.t1.hostload = n | Identifica o número de linhas de execução, n, a serem usadas para indexar itens simultaneamente. | 5 | Tente ajustar n com base na quantidade de carga que você quer colocar no repositório. Comece com valores iguais ou superiores a 10. |
schedule.pollQueueIntervalSecs = s | Identifica o número de segundos (s) a serem aguardados antes de uma nova pesquisa . O conector de conteúdo continua pesquisando itens, desde que a API retorne itens na resposta da pesquisa. Quando a resposta da enquete está vazia, o conector aguarda s segundos antes de tentar de novo. Essa configuração é usada apenas pelo ListingConnector. | 10 | Tente diminuir para 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Especifica os status (status1, status2 e …) dos itens a serem indexados. Por exemplo, definir status1 como NEW_ITEM e status2 como MODIFIED instrui o atravessador t1 a indexar somente itens com esses status. | Um atravessador verifica todos os status. | Teste ter diferentes atravessadores pesquisando diferentes status. |
Para mais informações sobre os parâmetros do arquivo de configuração, consulte Parâmetros de configuração fornecidos pelo Google.
Tempos limites ou interrupções do SDK durante o upload de arquivos grandes
Se o tempo limite do SDK for atingido ou houver interrupções ao fazer upload de arquivos grandes,
especificar um tempo limite maior usando
traverser.timeout=s
(em que s = número de segundos). Esse valor identifica por quanto tempo o worker
e as linhas de execução precisam
processar um item. O tempo limite padrão no SDK é de 60 segundos
para linhas de execução transversais. Além disso, se você tiver solicitações de API individuais
tempo limite, use os seguintes métodos para aumentar os valores de tempo limite da solicitação:
| Parâmetro de tempo limite de solicitação | Descrição | Padrão |
|---|---|---|
indexingService.connectTimeoutSeconds |
Conecte o tempo limite para indexar solicitações de API. | 120 segundos |
indexingService.readTimeoutSeconds |
Leia o tempo limite para indexar solicitações de API. | 120 segundos |