L'SDK Google Cloud Search contiene diversi parametri di configurazione forniti da Google utilizzati da tutti i connettori. Sapere come ottimizzare queste impostazioni può semplificare notevolmente l'indicizzazione dei dati. Questa guida elenca diversi problemi che possono verificarsi durante l'indicizzazione e le impostazioni utilizzate per risolverli.
Il throughput di 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 ulteriori APIOperation(). L'SDK attende l'elaborazione della partizione corrente prima di recuperare altri elementi. Questa impostazione dipende dalla quantità di memoria disponibile. Partizioni più piccole, ad esempio 50 o 100, richiedono meno memoria, ma più attesa da parte dell'SDK. |
50 | Se hai molta memoria disponibile, 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 batch dalla partizione. I batch più grandi richiedono un'attesa più lunga. | 10 | Prova a ridurre le dimensioni del batch. |
batch.maxActiveBatches |
Numero di batch eseguibili contemporaneamente consentiti. | 20 | Se abbassi batchSize, devi aumentare maxActiveBatches in base a questa formula: maxActiveBatches = (partitionSize / batchSize) + 50. Ad esempio, se il tuo partititionSize è 1000 e il tuo batchSize è 5, il tuo maxActiveBatches dovrebbe essere 250. I 50 in più 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 serie, ma le chiamate API vengono elaborate in parallelo utilizzando threadPoolSize thread. Ogni thread elabora un elemento alla volta. Il valore predefinito di 50 elabora al massimo solo 50 elementi contemporaneamente e richiede 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.
Il throughput di indicizzazione è basso per ListTraversalConnector
Per impostazione predefinita, un connettore che implementa ListTraversalConnnector utilizza un
unico traverser per indicizzare gli elementi. Per aumentare la velocità effettiva di indicizzazione, puoi
creare più traverser, ognuno con la propria configurazione incentrata su specifici
stati degli articoli (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ù traverser individuali in cui t1, t2, t3, ... è il nome univoco di ciascuno. Ogni traverser denominato ha il proprio insieme di impostazioni, identificate utilizzando il nome univoco del traverser, ad esempio traversers.t1.hostload e traversers.t2.hostload. | Un trasbordatore | Utilizza questa impostazione per aggiungere altri traverser |
traversers.t1.hostload = n | Identifica il numero di thread, n, da utilizzare per indicizzare simultaneamente gli elementi. | 5 | Sperimenta la regolazione di n in base al carico che vuoi esercitare sul 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, impostando status1 su NEW_ITEM e status2 su MODIFIED, il traverser t1 indicizza solo gli elementi con questi stati. | Un unico traverser controlla tutti gli stati | Prova a fare in modo che diversi traverser eseguano il polling per stati diversi. |
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 verifica un timeout o interruzioni 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
di lavoro per elaborare un elemento. Il timeout predefinito nell'SDK è di 60 secondi
per i thread traverser. Inoltre, se si verifica il timeout delle singole richieste API, utilizza i seguenti metodi per aumentare i valori di timeout delle richieste:
| Parametro di timeout della richiesta | Descrizione | Predefinito |
|---|---|---|
indexingService.connectTimeoutSeconds |
Timeout di connessione per le richieste API Indexing. | 120 secondi. |
indexingService.readTimeoutSeconds |
Timeout di lettura per le richieste API Indexing. | 120 secondi. |