L'SDK Google Cloud Search contiene diversi parametri di configurazione forniti da Google utilizzati da tutti i connettori. Sapere come ottimizzare queste impostazioni può snellire notevolmente l'indicizzazione dei dati. Questa guida elenca diversi problemi che possono verificarsi durante l'indicizzazione e le impostazioni utilizzate per risolverli.
Il throughput dell'indicizzazione è basso per FullTraversalConnector
La tabella seguente elenca le impostazioni di configurazione per migliorare il throughput di 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 tempi di attesa più lunghi per l'SDK. |
50 | Se hai molta memoria a disposizione, prova ad aumentare partitionSize a 1000 o più. |
batch.batchSize |
Il numero di richieste raggruppate. Al termine del partizionamento, l'SDK attende l'elaborazione di tutte le richieste raggruppate dalla partizione. I batch di dimensioni maggiori richiedono tempi di attesa più lunghi. | 10 | Prova a ridurre la dimensione del batch. |
batch.maxActiveBatches |
Numero di batch con esecuzione simultanea consentiti. | 20 | Se diminuisci batchSize, devi aumentare maxActiveBatches in base alla seguente formula: maxActiveBatches = (partitionSize / batchSize) + 50. Ad esempio, se partititionSize è 1000 e batchSize è 5, maxActiveBatches dovrebbe essere 250. I 50 extra sono un buffer per le richieste di ripetizione. 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 oggetti RepositoryDoc) in modo seriale, ma le chiamate API vengono elaborate in parallelo utilizzando threadPoolSize thread. Ogni thread elabora un elemento alla volta. Il valore predefinito di 50 consente di elaborare contemporaneamente al massimo 50 elementi e sono necessari circa 4 secondi per elaborare un singolo elemento (inclusa la richiesta di indicizzazione). |
50 | Prova ad aumentare threadPoolSize per un multiplo di 10. |
Infine, ti consigliamo di utilizzare il metodo setRequestMode() per modificare la modalità di richiesta dell'API (ASYNCHRONOUS o SYNCHRONOUS).
Per ulteriori informazioni sui parametri del file di configurazione, consulta Parametri di configurazione forniti da Google.
La velocità di indicizzazione è bassa per ListTraversalConnector
Per impostazione predefinita, un connettore che implementa ListTraversalConnnector utilizza un singolo visitatore per indicizzare gli elementi. Per aumentare il throughput dell'indicizzazione, puoi creare più esploratori, ognuno con la propria configurazione incentrata su stati degli elementi specifici (NEW_ITEM, MODIFIED e così via). La tabella seguente elenca le impostazioni di configurazione per migliorare il throughput:
| Impostazione | Descrizione | Predefinito | Modifica della configurazione da provare |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Crea uno o più singoli attraversatori, dove t1, t2, t3, ... è il nome univoco di ciascuno. Ogni esploratore denominato ha un proprio insieme di impostazioni che vengono identificate utilizzando il nome univoco dell'esploratore, ad esempio traversers.t1.hostload e traversers.t2.hostload. | Un attraversamento | Utilizza questa impostazione per aggiungere altri attraversamenti |
traversers.t1.hostload = n | Identifica il numero di thread, n, da utilizzare per indicizzare contemporaneamente gli elementi. | 5 | Prova a ottimizzare n in base al carico che vuoi applicare al tuo repository. Inizia con valori pari o superiori a 10. |
schedule.pollQueueIntervalSecs = s | Identifica il numero di secondi, s, da attendere prima di eseguire nuovamente il polling . Il connettore dei contenuti continua a eseguire il polling degli elementi finché l'API restituisce elementi nella risposta del polling. Quando la risposta al sondaggio è vuota, il connettore attende s secondi prima di riprovare. Questa impostazione viene utilizzata solo da ListingConnector | 10 | Prova a impostare il valore su 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Specifica gli stati status1, status2, … degli elementi da indicizzare. Ad esempio, impostare status1 su NEW_ITEM e status2 su MODIFIED indica all'esploratore t1 di indicizzare solo gli elementi con questi stati. | Un singolo visitatore controlla tutti gli stati | Prova a utilizzare diversi esploratori per eseguire il polling per stati diversi. |
Per ulteriori informazioni sui parametri del file di configurazione, consulta Parametri di configurazione forniti da Google.
Tempo di attesa 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,
specifica un timeout più lungo utilizzando
traverser.timeout=s
(dove s = numero di secondi). Questo valore identifica il tempo necessario ai thread worker per elaborare un elemento. Il timeout predefinito nell'SDK è di 60 secondi per i thread di attraversamento. Inoltre, se le singole richieste API superano il timeout, utilizza i seguenti metodi per aumentare i valori di timeout delle richieste:
| Parametro di timeout della richiesta | Descrizione | Predefinito |
|---|---|---|
indexingService.connectTimeoutSeconds |
Tempo di attesa per la connessione per le richieste dell'API di indicizzazione. | 120 secondi. |
indexingService.readTimeoutSeconds |
Tempo di attesa di lettura per le richieste API di indicizzazione. | 120 secondi. |