Le SDK Google Cloud Search contient plusieurs paramètres de configuration fournis par Google et utilisés par tous les connecteurs. Savoir régler ces paramètres peut considérablement rationaliser l'indexation des données. Ce guide répertorie plusieurs problèmes pouvant survenir lors de l'indexation et les paramètres utilisés pour les résoudre.
Débit d'indexation faible pour FullTraversalConnector
Le tableau suivant répertorie les paramètres de configuration permettant d'améliorer le débit pour un connecteur FullTraversalConnector:
| Paramètre | Description | Par défaut | Modifier la configuration à essayer |
|---|---|---|---|
traverse.partitionSize |
Nombre d'ApiOperation() à traiter par lots avant la récupération de 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 partitions plus petites, telles que 50 ou 100, nécessitent moins de mémoire, mais davantage d'attentes pour le compte du SDK. |
50 | Si vous avez beaucoup de mémoire disponible, 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 de la partition soient traitées. Les lots plus volumineux nécessitent un temps d'attente plus long. | 10 | Essayez de réduire la taille de lot. |
batch.maxActiveBatches |
Nombre de lots autorisés en cours d'exécution simultanée. | 20 | Si vous réduisez la valeur de batchSize, vous devez repousser maxActiveBatches selon la formule suivante: maxActiveBatches = (partitionSize / batchSize) + 50. Par exemple, si votre partititionSize est de 1 000 et que votre batchSize est de 5, votre maxActiveBatches devrait être de 250. Les 50 pas supplémentaires constituent un tampon pour les nouvelles tentatives de requêtes. Cette augmentation permet au connecteur de traiter toutes les requêtes par lot, sans les bloquer. |
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) en série, mais les appels d'API les traitent en parallèle en utilisant le nombre de threads de threadPoolSize. Chaque thread traite un élément à la fois. Avec la valeur par défaut 50, seuls 50 éléments maximum sont traités simultanément. Le traitement d'un élément individuel (demande d'indexation incluse) prend environ 4 secondes. |
50 | Essayez d'augmenter threadPoolSize par un multiple de 10. |
Enfin, envisagez d'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 le ListTraversalConnnector a recours à un simple balayage pour indexer les éléments. Pour augmenter le débit d'indexation, vous pouvez créer plusieurs balayages, chacun avec sa propre configuration, en se concentrant sur des états d'éléments spécifiques (NEW_ITEM, MODIFIED, etc.). Le tableau suivant répertorie les paramètres de configuration permettant d'améliorer le débit:
| Paramètre | Description | Par défaut | Modifier la configuration à essayer |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Crée un ou plusieurs balayages individuels, où t1, t2, t3, ... est le nom unique de chacun d'eux. Chaque balayage nommé possède son propre ensemble de paramètres, identifiés par un nom unique, tel que traversers.t1.hostload et traversers.t2.hostload. | Un balayage | Utilisez ce paramètre pour ajouter des balayages supplémentaires |
traversers.t1.hostload = n | Identifie le nombre de threads (n) à utiliser pour indexer simultanément des éléments. | 5 | Testez le réglage de n en fonction de la charge que vous souhaitez appliquer à votre dépôt. Commencez par des valeurs supérieures ou égales à 10. |
schedule.pollQueueIntervalSecs = s | Identifie le nombre de secondes (s) d'attente avant le nouveau sondage . Le connecteur de contenu continue d'interroger les éléments tant que l'API les renvoie dans la réponse au sondage. Lorsque la réponse au sondage est vide, le connecteur attend s secondes avant de réessayer. Ce paramètre n'est utilisé que par le service | 10 | Essayez de descendre à 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 balayage t1 d'indexer uniquement les éléments avec ces états. | Un balayage vérifie tous les états | Essayez d'utiliser différents balayages 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.
Interruptions ou interruptions du SDK lors de l'importation de fichiers volumineux
Si vous rencontrez des interruptions ou des délais avant expiration du SDK lors de l'importation de fichiers volumineux, spécifiez un délai avant expiration plus élevé à l'aide de traverser.timeout=s (où s = nombre de secondes). Cette valeur identifie la durée dont disposent les threads de calcul pour traiter un élément. Le délai avant expiration par défaut dans le SDK est de 60 secondes pour les threads de balayage. En outre, si des requêtes API individuelles dépassent le délai, utilisez les méthodes suivantes pour augmenter les valeurs du 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 d'expiration de la connexion pour l'indexation des requêtes API. | 120 secondes. |
indexingService.readTimeoutSeconds |
Délai de lecture pour l'indexation des requêtes API. | 120 secondes. |