Le SDK Google Cloud Search contient plusieurs paramètres de configuration fournis par Google qui sont 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.
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 d'ApiOperation() à traiter par lots avant de récupérer d'autres APIOperation(). Le SDK attend que la partition actuelle soit traitée avant de récupérer 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'attente pour le SDK. |
50 | Si vous avez beaucoup de mémoire disponible, essayez de passer 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 depuis la partition. 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 à exécuter simultanément. | 20 | Si vous diminuez la valeur batchSize, vous devez augmenter la valeur 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 supplémentaires sont un tampon pour les nouvelles requêtes. Cette augmentation permet au connecteur de regrouper toutes les requêtes sans les bloquer. |
traverse.threadPoolSize |
Nombre de threads créés par le connecteur pour permettre un traitement en parallèle. Un seul itérateur récupère les opérations (généralement des objets RepositoryDoc) en série, mais les appels d'API sont traités en parallèle en utilisant un nombre de threads threadPoolSize. Chaque thread traite un élément à la fois. La valeur par défaut de 50 permet de traiter au maximum 50 éléments simultanément et le traitement d'un élément individuel (y compris la demande d'indexation) prend environ 4 secondes. |
50 | Essayez d'augmenter la valeur 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 plus d'informations sur les paramètres du 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 mettant en œuvre ListTraversalConnnector utilise un seul balayage pour indexer vos éléments. Pour augmenter le débit d'indexation, vous pouvez créer plusieurs balayages, chacun avec sa propre configuration, en vous concentrant sur des états d'élément 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 | Modification de configuration à essayer |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Crée un ou plusieurs traverseurs individuels, où t1, t2, t3, ... est le nom unique de chacun d'eux. Chaque traverseur nommé possède son propre ensemble de paramètres, identifiés à l'aide du nom unique du balayage (par exemple, traversers.t1.hostload et traversers.t2.hostload). | Un traverseur | Utilisez ce paramètre pour ajouter des traverseurs supplémentaires |
traversers.t1.hostload = n | Identifie le nombre de fils de discussion (n) à utiliser pour indexer simultanément des é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 supérieures ou égales à 10. |
schedule.pollQueueIntervalSecs = s | Identifie le nombre de secondes (s) d'attente avant de renvoyer une requête . Le connecteur de contenu continue d'interroger des éléments tant que l'API renvoie des éléments dans la réponse au sondage. Si la réponse au sondage 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 l'état (status1, status2, …) des éléments à indexer. Par exemple, si vous définissez status1 sur NEW_ITEM et status2 sur MODIFIED, le système de navigation t1 n'indexe que les éléments ayant ces états. | Un traverseur vérifie tous les états | Faites des tests en interrogeant différents états selon leur état. |
Pour plus d'informations sur les paramètres du fichier de configuration, consultez la section Paramètres de configuration fournis par Google.
Délais d'expiration ou interruptions du SDK lors de l'importation de fichiers volumineux
Si le délai avant expiration du SDK ou des interruptions se produisent lors de l'importation de fichiers volumineux, spécifiez un délai avant expiration plus important à l'aide de traverser.timeout=s (où s correspond au nombre de secondes). Cette valeur identifie le temps 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 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 d'expiration de la connexion pour l'indexation des requêtes API. | 120 secondes. |
indexingService.readTimeoutSeconds |
Délai d'expiration de la lecture pour l'indexation des requêtes API. | 120 secondes. |