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 grandement simplifier l'indexation des données. Ce guide liste plusieurs problèmes qui peuvent survenir lors de l'indexation, ainsi que les paramètres utilisés pour les résoudre.
Le débit d'indexation est faible pour FullTraversalConnector
Le tableau suivant répertorie 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 lots avant de récupérer des APIOperation() supplémentaires. Le SDK attend que la partition actuelle soit traitée avant de récupérer d'autres éléments. Ce paramètre dépend de la quantité de mémoire disponible. Les partitions de plus petite taille (50 ou 100, par exemple) nécessitent moins de mémoire, mais le SDK doit attendre plus longtemps. |
50 | Si vous disposez de beaucoup de mémoire, essayez d'augmenter partitionSize à 1 000 ou plus. |
batch.batchSize |
Nombre de requêtes regroupées. À la fin du partitionnement, le SDK attend que toutes les requêtes par lot soient traitées à partir de la partition. Les lots plus volumineux nécessitent un temps d'attente plus long. | 10 | Essayez de réduire la taille du 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 de 1 000 et votre batchSize de 5, votre maxActiveBatches doit être de 250. Les 50 unités supplémentaires servent de marge pour les demandes de réessai. Cette augmentation permet au connecteur de regrouper toutes les demandes sans blocage. |
traverse.threadPoolSize |
Nombre de threads créés par le connecteur pour permettre le traitement en parallèle. Un seul itérateur récupère les opérations (généralement des objets RepositoryDoc) de manière séquentielle, mais les appels d'API sont traités en parallèle à l'aide du nombre de threads threadPoolSize. Chaque thread traite un élément à la fois. La valeur par défaut de 50 signifie que seuls 50 éléments au maximum seront traités simultanément. Le traitement d'un élément individuel prend environ quatre secondes (y compris la demande d'indexation). |
50 | Essayez d'augmenter threadPoolSize par un multiple de 10. |
Enfin, vous pouvez utiliser la méthode setRequestMode() pour modifier le mode de requête API (ASYNCHRONOUS ou SYNCHRONOUS).
Pour en savoir plus sur les paramètres du fichier de configuration, consultez Paramètres de configuration fournis par Google.
Le débit d'indexation est faible pour ListTraversalConnector
Par défaut, un connecteur qui implémente ListTraversalConnnector utilise un seul traverser pour indexer vos éléments. Pour augmenter le débit d'indexation, vous pouvez créer plusieurs traversers, chacun avec sa propre configuration axée sur des états d'éléments spécifiques (NEW_ITEM, MODIFIED, etc.). Le tableau suivant liste 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 traversers individuels, où t1, t2, t3, ... est le nom unique de chacun d'eux. Chaque traverser nommé possède son propre ensemble de paramètres, identifiés à l'aide du nom unique du traverser, tels que traversers.t1.hostload et traversers.t2.hostload. | Un seul traversier | Utilisez ce paramètre pour ajouter des traversées supplémentaires. |
traversers.t1.hostload = n | Identifie le nombre de threads, n, à utiliser pour indexer simultanément les éléments. | 5 | Testez le réglage de n en fonction de la charge que vous souhaitez imposer à votre dépôt. Commencez par des valeurs de 10 ou plus. |
schedule.pollQueueIntervalSecs = s | Identifie le nombre de secondes (s) à attendre avant d'interroger à nouveau . Le connecteur de contenu continue d'interroger les éléments tant que l'API renvoie des éléments dans la réponse à l'interrogation. Lorsque la réponse à la requête 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 et … des éléments à indexer. Par exemple, si vous définissez status1 sur NEW_ITEM et status2 sur MODIFIED, le traverser t1 n'indexe que les éléments ayant ces états. | Un seul traverser vérifie tous les états | Testez différents traversers pour interroger différents états. |
Pour en savoir plus sur les paramètres du fichier de configuration, consultez Paramètres de configuration fournis par Google.
Délai d'expiration ou interruption du SDK lors de l'importation de fichiers volumineux
Si vous rencontrez des délais 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 worker 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. De plus, si vous constatez que des requêtes API individuelles expirent, utilisez les méthodes suivantes pour augmenter les valeurs de délai d'expiration des requêtes :
| Paramètre de délai avant expiration de la requête | Description | Par défaut |
|---|---|---|
indexingService.connectTimeoutSeconds |
Délai de connexion pour les requêtes de l'API d'indexation. | 120 secondes. |
indexingService.readTimeoutSeconds |
Délai avant expiration de la lecture pour les requêtes de l'API d'indexation. | 120 secondes. |