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 simplificar muito 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 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ê reduzir batchSize, aumente maxActiveBatches de acordo com esta fórmula: maxActiveBatches = (partitionSize / batchSize) + 50. Por exemplo, se a partititionSize for 1.000 e a batchSize for 5, a maxActiveBatches vai precisar 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 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, 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 a 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 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 o próprio conjunto de configurações, que são identificados pelo nome exclusivo dele, 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 aguardar 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 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 SDK apresentar interrupções ou expirar durante o 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
de worker têm para processar um item. O tempo limite padrão no SDK é de 60 segundos
para as linhas de execução do atravessar. Além disso, se o tempo limite de solicitações de API individuais expirar, use os métodos a seguir 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 |