L'SDK di Google Cloud Search contiene diverse configurazioni fornite da Google utilizzati da tutti i connettori. Sapere come ottimizzare queste impostazioni può semplifica notevolmente l'indicizzazione dei dati. Questa guida elenca diversi problemi che possono essere visualizzati durante l'indicizzazione e le impostazioni usate per risolverle.
La velocità effettiva di indicizzazione è bassa per FullTraversalConnector
La tabella seguente elenca le impostazioni di configurazione per migliorare la velocità effettiva per un FullTraversalConnector:
| Impostazione | Descrizione | Predefinito | Modifica della configurazione da provare |
|---|---|---|---|
traverse.partitionSize |
Il numero di ApiOperation() da elaborare in batch prima di recuperare altri APIOperation(). L'SDK attende l'elaborazione della partizione corrente prima di recuperare altri elementi. Questa impostazione dipende dalla quantità di memoria disponibile. Dimensioni delle partizioni più piccole, ad esempio 50 o 100, richiedono meno memoria, ma più tempo in attesa da parte dell'SDK. |
50 | Se hai molta memoria disponibile, prova ad aumentare partitionSize impostandolo su 1000 o più. |
batch.batchSize |
Il numero di richieste raggruppate insieme. Al termine del partizionamento, l'SDK attende l'elaborazione di tutte le richieste in batch dalla partizione. I batch di grandi dimensioni richiedono un'attesa più lunga. | 10 | Prova a ridurre la dimensione del batch. |
batch.maxActiveBatches |
Numero di batch consentiti in esecuzione contemporaneamente. | 20 | Se abbassi batchSize, devi aumentare il valore di maxActiveBatches in base a questa formula: maxActiveBatches = (partitionSize / batchSize) + 50. Ad esempio, se partititionSize è 1000 e batchSize è 5, maxActiveBatches dovrebbe essere 250. mentre altri 50 sono un buffer per le richieste di nuovo tentativo. Questo aumento consente al connettore di raggruppare tutte le richieste senza blocchi. |
traverse.threadPoolSize |
Numero di thread creati dal connettore per consentire l'elaborazione parallela. Un singolo iteratore recupera le operazioni (in genere RepositoryDoc oggetti) in modo seriale, ma le chiamate API vengono elaborate in parallelo utilizzando threadPoolSize numero di thread. Ogni thread elabora un elemento alla volta. Il valore predefinito 50 elaborerebbe al massimo 50 elementi contemporaneamente e occorrono circa 4 secondi per elaborare un singolo elemento (inclusa la richiesta di indicizzazione). |
50 | Prova ad aumentare threadPoolSize di un multiplo di 10. |
Infine, valuta la possibilità di utilizzare il metodo setRequestMode() per modificare la modalità di richiesta API (ASYNCHRONOUS o SYNCHRONOUS).
Per ulteriori informazioni sui parametri del file di configurazione, consulta Parametri di configurazione forniti da Google.
La velocità effettiva di indicizzazione è bassa per ListTraversalConnector
Per impostazione predefinita, un connettore che implementa il ListTraversalConnnector utilizza un
singolo container per indicizzare gli elementi. Per aumentare la velocità effettiva di indicizzazione, puoi
creare più vettori, ciascuno con la propria configurazione focalizzata su
stati degli articoli (NEW_ITEM, MODIFIED e così via). Nella tabella seguente sono elencati i
di configurazione per migliorare la velocità effettiva:
| Impostazione | Descrizione | Predefinito | Modifica della configurazione da provare |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Crea uno o più trasferimenti individuali dove t1, t2, t3, ... è il nome univoco di ciascuno. Ogni traverser denominato ha il proprio insieme di impostazioni, che vengono identificate utilizzando il suo nome univoco, ad esempio traversers.t1.hostload e traversers.t2.hostload | Un traverser | Utilizza questa impostazione per aggiungere altri attraversatori |
traversers.t1.hostload = n | Identifica il numero di thread, n, da utilizzare per indicizzare contemporaneamente gli elementi. | 5 | Sperimenta con l'ottimizzazione di n in base al carico che vuoi applicare al repository. Inizia con valori pari o superiori a 10. |
schedule.pollQueueIntervalSecs = s | Identifica il numero di secondi (s) di attesa prima di eseguire nuovamente il polling . Il connettore di contenuti continua a eseguire il polling degli elementi finché l'API restituisce gli elementi nella risposta del sondaggio. Quando la risposta al sondaggio è vuota, il connettore attende s secondi prima di riprovare. Questa impostazione viene utilizzata solo da ProfileConnector | 10 | Prova a ridurla a 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Specifica gli stati (status1, status2, …) degli elementi da indicizzare. Ad esempio, l'impostazione di status1 su NEW_ITEM e di status2 su MODIFIED indica al trasferimento t1 di indicizzare solo gli elementi con quegli stati. | Un traverser controlla tutti gli stati | Prova a fare in modo che traverser diversi svolgano sondaggi per stati differenti. |
Per ulteriori informazioni sui parametri del file di configurazione, consulta Parametri di configurazione forniti da Google.
Timeout o interruzioni dell'SDK durante il caricamento di file di grandi dimensioni
Se si verificano interruzioni o timeout dell'SDK durante il caricamento di file di grandi dimensioni,
specificare un timeout maggiore utilizzando
traverser.timeout=s
(dove s = numero di secondi). Questo valore identifica quanto tempo
i thread devono elaborare un elemento. Il timeout predefinito nell'SDK è 60 secondi
per i traverser thread. Inoltre, se ricevi richieste API individuali,
utilizza i seguenti metodi per aumentare i valori di timeout della richiesta:
| Parametro di timeout della richiesta | Descrizione | Predefinito |
|---|---|---|
indexingService.connectTimeoutSeconds |
Timeout della connessione per l'indicizzazione delle richieste API. | 120 secondi. |
indexingService.readTimeoutSeconds |
Timeout di lettura per l'indicizzazione delle richieste API. | 120 secondi. |