Le SDK Google Cloud Search contient plusieurs paramètres de configuration fournis par Google qui sont utilisés par tous les connecteurs. Savoir comment ajuster ces paramètres peut considérablement simplifier l'indexation des données. Ce guide liste plusieurs problèmes pouvant survenir lors de l'indexation et les paramètres utilisés pour les résoudre.
Le débit d'indexation est faible pour FullTraversalConnector
Le tableau suivant présente les paramètres de configuration permettant d'améliorer le débit d'un FullTraversalConnector:
| Paramètre | Description | Par défaut | Modification de configuration à essayer |
|---|---|---|---|
traverse.partitionSize |
Nombre de ApiOperation() à traiter par lot avant d'extraire des APIOperation() supplémentaires. Le SDK attend que la partition actuelle soit traitée avant d'extraire des éléments supplémentaires. Ce paramètre dépend de la quantité de mémoire disponible. Les tailles de partition plus petites, telles que 50 ou 100, nécessitent moins de mémoire, mais plus d'attente de la part du SDK. |
50 | Si vous disposez de beaucoup de mémoire disponible, essayez d'augmenter partitionSize à 1 000 ou plus. |
batch.batchSize |
Nombre de requêtes groupées. À la fin du partitionnement, le SDK attend que toutes les requêtes groupées soient traitées à partir de la partition. Les lots plus importants nécessitent un temps d'attente plus long. | 10 | Essayez de réduire la taille de lot. |
batch.maxActiveBatches |
Nombre de lots pouvant être exécutés simultanément. | 20 | Si vous diminuez batchSize, vous devez augmenter maxActiveBatches selon la formule suivante: maxActiveBatches = (partitionSize / batchSize) + 50. Par exemple, si votre partititionSize est 1 000 et votre batchSize est 5, votre maxActiveBatches doit être 250. Les 50 octets supplémentaires sont un tampon pour les requêtes de nouvelle tentative. Cette augmentation permet au connecteur de regrouper toutes les requêtes sans blocage. |
traverse.threadPoolSize |
Nombre de threads créés par le connecteur pour permettre le traitement en parallèle. Un seul itérateur extrait les opérations (généralement des objets RepositoryDoc) de manière séquentielle, mais le processus d'appels d'API est parallèle et utilise un nombre de threads threadPoolSize. Chaque thread traite un élément à la fois. La valeur par défaut de 50 articles ne permet de traiter que 50 articles simultanément. Le traitement d'un article individuel prend environ quatre secondes (y compris la requête d'indexation). |
50 | Essayez d'augmenter threadPoolSize d'un multiple de 10. |
Enfin, envisagez d'utiliser la méthode setRequestMode() pour modifier le mode de requête de l'API (ASYNCHRONOUS ou SYNCHRONOUS).
Pour en savoir plus sur les paramètres de fichier de configuration, consultez la section Paramètres de configuration fournis par Google.
Le débit d'indexation est faible pour ListTraversalConnector.
Par défaut, un connecteur qui implémente ListTraversalConnector utilise un seul explorateur pour indexer vos éléments. Pour augmenter le débit d'indexation, vous pouvez créer plusieurs explorateurs, chacun avec sa propre configuration axée sur des états d'éléments spécifiques (NEW_ITEM, MODIFIED, etc.). Le tableau suivant présente les paramètres de configuration permettant d'améliorer le débit:
| Paramètre | Description | Par défaut | Modification de configuration à essayer |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Crée un ou plusieurs explorateurs individuels, où t1, t2, t3, ... est le nom unique de chacun. Chaque explorateur nommé possède son propre ensemble de paramètres, qui sont identifiés à l'aide du nom unique de l'explorateur, par exemple traversers.t1.hostload et traversers.t2.hostload. | Un traversée | Utilisez ce paramètre pour ajouter des explorateurs supplémentaires. |
traversers.t1.hostload = n | Indique le nombre de threads, n, à utiliser pour indexer simultanément des éléments. | 5 | Essayez d'ajuster n en fonction de la charge que vous souhaitez appliquer à votre dépôt. Commencez par des valeurs de 10 ou plus. |
schedule.pollQueueIntervalSecs = s | Indique le nombre de secondes (s) à attendre avant de relancer la requête . Le connecteur de contenu continue d'interroger les éléments tant que l'API renvoie des éléments dans la réponse d'interrogation. Lorsque la réponse d'interrogation est vide, le connecteur attend s secondes avant de réessayer. Ce paramètre n'est utilisé que par ListingConnector. | 10 | Essayez de le réduire à 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Spécifie les états, status1, status2, …, des éléments à indexer. Par exemple, définir status1 sur NEW_ITEM et status2 sur MODIFIED indique au traverseur t1 d'indexer uniquement les éléments associés à ces états. | Un seul explorateur vérifie tous les états. | Essayez de faire en sorte que différents explorateurs interrogent différents états. |
Pour en savoir plus sur les paramètres de fichier de configuration, consultez la section Paramètres de configuration fournis par Google.
Délais avant expiration ou interruptions du SDK lors de l'importation de fichiers volumineux
Si vous rencontrez un délai avant expiration ou des interruptions du SDK lors de l'importation de fichiers volumineux, spécifiez un délai avant expiration plus long à l'aide de traverser.timeout=s (où s correspond au nombre de secondes). Cette valeur indique la durée pendant laquelle les threads de travail doivent traiter un élément. Le délai avant expiration par défaut dans le SDK est de 60 secondes pour les threads de traversée. En outre, si des requêtes API individuelles expirent, utilisez les méthodes suivantes pour augmenter les valeurs de délai avant expiration des requêtes:
| Paramètre de délai avant expiration de la requête | Description | Par défaut |
|---|---|---|
indexingService.connectTimeoutSeconds |
Délai avant expiration de la connexion pour les requêtes API d'indexation. | 120 secondes. |
indexingService.readTimeoutSeconds |
Délai avant expiration de lecture pour les requêtes de l'API d'indexation. | 120 secondes. |