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 otimizar bastante a indexação de dados. Este guia lista vários problemas que podem surgir 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 um 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 outras 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 1000 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ê reduzir batchSize, você precisa aumentar maxActiveBatches de acordo com a fórmula: maxActiveBatches = (partitionSize / batchSize) + 50. Por exemplo, se partititionSize for 1.000 e batchSize for 5, maxActiveBatches 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 o número de linhas de execução threadPoolSize. 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, use 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
único atravessador para indexar seus itens. Para aumentar a capacidade de indexação, é possível
criar vários atravessadores, cada um com sua própria configuração, com foco em status específicos
de item (NEW_ITEM, MODIFIED etc.). A tabela a seguir lista
as definições de configuração para melhorar a capacidade:
| 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 elemento de passagem nomeado tem um conjunto de configurações identificado pelo nome exclusivo, 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 seu repositório. Comece com valores iguais ou superiores a 10. |
schedule.pollQueueIntervalSecs = s | Identifica o número de segundos, s, a esperar antes da nova pesquisa . O conector de conteúdo continua pesquisando itens, desde que a API retorne itens na resposta da pesquisa. Quando essa resposta está vazia, o conector aguarda s segundos antes de tentar novamente. Essa configuração é usada apenas pelo ListingConnector. | 10 | Tente diminuir para 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Especifica os status status1, status2, … dos itens para indexar. Por exemplo, definir status1 como NEW_ITEM e status2 como MODIFIED instrui o t1 a indexar apenas os 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 você tiver um tempo limite ou interrupções do SDK ao fazer upload de arquivos grandes,
especifique um tempo limite maior usando
traverser.timeout=s
(em que s = número de segundos). Esse valor identifica quanto tempo as linhas de execução
do worker têm para processar um item. O tempo limite padrão no SDK é de 60 segundos
para linhas de execução de atravessador. Além disso, se o tempo limite de solicitações de API individuais
esgotar, 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 |