Le SDK Google Cloud Search contient plusieurs configurations fournies par Google paramètres utilisés par tous les connecteurs. Savoir comment régler ces paramètres peut considérablement simplifier l'indexation des données. Ce guide répertorie plusieurs problèmes peuvent apparaître 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 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 au nom 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 utilise un
pour indexer vos éléments. Pour augmenter le débit d'indexation, vous pouvez
créez plusieurs balayages, chacun avec sa propre configuration, en vous concentrant sur des
les états des articles (NEW_ITEM, MODIFIED, etc.). Le tableau suivant répertorie
afin 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 subissez un délai d'inactivité du SDK ou des interruptions
lors de l'importation de fichiers volumineux,
spécifier un délai plus long en utilisant
traverser.timeout=s
(où s = nombre de secondes). Cette valeur identifie la durée pendant laquelle
les threads doivent
traiter un élément. Le délai avant expiration par défaut dans le SDK est de 60 secondes
pour les fils de discussion de balayage. De plus, si vous recevez des requêtes API individuelles
, utilisez les méthodes suivantes pour augmenter ces valeurs:
| 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. |