L'SDK Google Cloud Search contiene diversi parametri di configurazione forniti da Google utilizzati da tutti i connettori. Sapere come regolare queste impostazioni può semplificare notevolmente l'indicizzazione dei dati. Questa guida elenca diversi problemi che possono emergere durante l'indicizzazione e le impostazioni utilizzate per risolverli.
La velocità effettiva di indicizzazione è bassa per FullTraversalConnector
La seguente tabella 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 elementi aggiuntivi. Questa impostazione dipende dalla quantità di memoria disponibile. Dimensioni delle partizioni più piccole, come 50 o 100, richiedono meno memoria, ma più attesa da parte dell'SDK. |
50 | Se hai molta memoria disponibile, prova ad aumentare partitionSize fino a 1000 o più. |
batch.batchSize |
Il numero di richieste raggruppate. Al termine del partizionamento, l'SDK attende che tutte le richieste in batch vengano elaborate dalla partizione. I batch più grandi richiedono un'attesa più lunga. | 10 | Prova a ridurre le dimensioni del batch. |
batch.maxActiveBatches |
Numero di batch consentiti in esecuzione contemporaneamente. | 20 | Se riduci batchSize, dovresti aumentare maxActiveBatches in base alla seguente 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 extra sono un buffer per le richieste di nuovo tentativo. Questo aumento consente al connettore di raggruppare tutte le richieste senza bloccarsi. |
traverse.threadPoolSize |
Numero di thread creati dal connettore per consentire l'elaborazione in parallelo. Un singolo iteratore recupera le operazioni (in genere RepositoryDoc oggetti) in serie, ma le chiamate API vengono elaborate in parallelo utilizzando threadPoolSize di thread. Ogni thread elabora un elemento alla volta. Il valore predefinito 50 elaborerebbe al massimo 50 elementi contemporaneamente e richiede circa 4 secondi per elaborare un singolo articolo (inclusa la richiesta di indicizzazione). |
50 | Prova ad aumentare il valore 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 ListTraversalConnnector utilizza un singolo traverser per indicizzare gli elementi. Per aumentare la velocità effettiva di indicizzazione, puoi
creare più traverser, ognuno con la propria configurazione incentrata su
stati specifici degli elementi (NEW_ITEM, MODIFIED e così via). La seguente tabella elenca le impostazioni di configurazione per migliorare la velocità effettiva:
| Impostazione | Descrizione | Predefinito | Modifica della configurazione da provare |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Crea uno o più traverser singoli dove t1, t2, t3, ... è il nome univoco di ciascuno. Ogni traverser denominato ha il proprio insieme di impostazioni, che vengono identificate usando il nome univoco dell'utente, come traversers.t1.hostload e traversers.t2.hostload | Un traverser | Utilizza questa impostazione per aggiungere altri traversi |
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 repository. Inizia con valori pari o superiori a 10. |
schedule.pollQueueIntervalSecs = s | Identifica il numero di secondi, s, di attesa prima di ripetere il sondaggio . Il connettore di contenuti continua a eseguire il polling degli elementi finché l'API non restituisce gli elementi nella risposta al sondaggio. Quando la risposta del sondaggio è vuota, il connettore attende s secondi prima di riprovare. Questa impostazione viene utilizzata solo da ListingsConnector | 10 | Prova ad abbassare 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 all'operatore t1 di indicizzare solo gli elementi con questi stati. | Un traverser controlla tutti gli stati | Prova a far sì che i traversini eseguano il polling in base allo stato. |
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 timeout o interruzioni dell'SDK durante il caricamento di file di grandi dimensioni,
specifica un timeout maggiore utilizzando
traverser.timeout=s
(dove s = numero di secondi). Questo valore identifica il tempo a disposizione
dei thread worker per elaborare un elemento. Il timeout predefinito nell'SDK è di 60 secondi per i thread del traverser. Inoltre, se si verificano tempi di esecuzione di singole richieste API, 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 le richieste API di indicizzazione. | 120 secondi. |
indexingService.readTimeoutSeconds |
Timeout di lettura per le richieste API di indicizzazione. | 120 secondi. |