Taille de pool de base de données et instances d'exécution

Dans la plupart des environnements Spectrum™ Technology Platform, il existe plusieurs flux en cours d’exécution en même temps, qu’ils s'agisse de traitements par lots ou de services répondant à un service Web ou à des requêtes d'API. Pour optimiser le traitement simultané, vous pouvez utiliser le paramètre de taille de pool de base de données, qui limite le nombre de requêtes simultanées gérées par une base de données Spectrum, et les instances d’exécution, qui contrôlent le nombre d’instances d’un stage de flux exécutées de manière simultanée. Ces deux paramètres doivent être réglés ensemble pour obtenir des performances optimales.

Taille de pool de base de données

Les ressources de base de données contiennent des données de référence utilisées par certains stages, comme les données postales utilisées pour valider des adresses ou les données de géocodage utilisées pour géocoder des adresses. Ces ressources de base de données peuvent être configurées pour accepter plusieurs demandes simultanées provenant des stages de dataflows ou des services qui les utilisent, améliorant ainsi les performances des dataflows ou des demandes de service. La taille de pool de base de données détermine le nombre maximal de requêtes simultanées qu'une base de données Spectrum peut traiter. Par défaut, les bases de données Spectrum disposent d'une taille de pool de 4, ce qui signifie que la base de données peut traiter quatre demandes simultanément.

La taille de pool optimale varie en fonction du module. En général, vous verrez les meilleurs résultats en définissant la taille de pool entre la moitié à deux fois le nombre d'unités centrales sur le serveur, avec une taille de pool optimale de la plupart des modules identique au nombre d'unités centrales. Par exemple, si votre serveur dispose de quatre unités centrales que vous souhaitez expérimenter avec une taille de pool comprise entre 2 (la moitié du nombre d'unités centrales) et 8 (deux fois le nombre d'unités centrales) avec la taille optimale étant probablement 4 (le nombre d'unités centrales).

Lors de la modification de la taille de pool, vous devez également considérer le nombre d'instances d'exécution indiquées dans le dataflow pour les stages accédant à la base de données. Considérez par exemple un flux de données disposant d'un stage Geocode US Address configuré pour utiliser une instance d'exécution. Si vous définissez la taille de pool de la base de données de géocodage des États-Unis, vous ne verrez pas d'amélioration des performances, car il n'y aurait qu'une instance d'exécution et donc il n'y aurait qu'une demande à la fois dans la base de données. Cependant, si vous souhaitez augmenter le nombre d'instances d'exécution de Geocode US Address à quatre, vous pouvez voir une amélioration de performances dans la mesure où il y aurait quatre instances de Geocode US Address accédant à la ressource de base de données simultanément, utilisant ainsi le pool entier.

Instances d'exécution (Runtime)

Chaque stage dans un flux de données fonctionne de manière asynchrone dans son propre thread et est indépendant de tout autre stage. Ceci permet le traitement parallèle des stages dans un flux de données, ce qui vous permet d'utiliser plus d'une instance d'exécution pour un stage. Ceci s'avère utile dans les flux de données dans lesquels certains stages traitent les données plus vite que d'autres.Cela peut mener à une distribution non équilibrée du travail parmi les threads.Par exemple, prenons un flux de données composé des stages suivants :



Selon la configuration de ces stages, il est possible que le stage Validate Address traite les enregistrements plus vite que le stage Geocode US Address. Si tel est le cas, à un certain moment de l'exécution du flux de données, tous les enregistrements auront été traités par Validate Address, mais Geocode US Address aura encore des enregistrements à traiter. Afin d'améliorer la performance de ce flux de données, il est nécessaire d'améliorer la performance du stage qui est le plus lent - dans notre cas, Geocode US Address. Une manière d'accomplir cela est de spécifier plusieurs instances d'exécution du stage. Régler le nombre d'instances d'exécution sur deux, par exemple, signifie qu'il y aura deux instances de ce stage, chacune s'exécutant dans son propre thread, disponible pour le traitement de vos enregistrements.

En règle générale, le nombre d'instances d'exécution devrait être au minimum égal au nombre d'instances du composant distant. Pour des informations sur les composants distants, reportez-vous au Guide d'administration . Bien que la spécification de plusieurs instances d'exécution puisse vous aider à améliorer la performance, définir une valeur trop élevée peut être néfaste pour vos ressources système, ce qui aura pour résultat une diminution de la performance.

Remarque : L'utilisation de plusieurs instances d'exécution n'améliore la performance que lors de l'exécution de jobs ou de requêtes de services avec plus d'un enregistrement.

Procédure de réglage fin

Pour trouver les bons réglages pour la taille de pool de base de données et le nombre d'instances d'exécution, il convient d'expérimenter différents réglages pour trouver ceux qui maximisent les ressources du serveur sans les surcharger ni réduire les performances.

Remarque : Avant d'affiner la taille de pool de base de données, nous vous conseillons d'optimiser la taille de pool de flux de données. Pour plus d'informations sur l'optimisation de la taille de pool de flux de données, reportez-vous à la section Taille de pool de flux de données.
  1. Commencez par rechercher des exemples de données à utiliser pour tester différents réglages. L'exemple de jeu de données doit être suffisamment important pour que le temps d'exécution soit mesurable et qu'il puisse être validé à des fins de cohérence. Les exemples de données doivent aussi être représentatifs des données réelles que vous souhaitez traiter. Par exemple, si vous effectuez un test des performances de géocodage, assurez-vous que vos données de test disposent d'un nombre équivalent d'enregistrements pour tous les pays que vous avez l'intention de géocoder.
  2. Si vous testez un service ou un flux de données qui requiert l'utilisation d'une ressource de base de données, comme des bases de données postales ou des bases de données de géocodage, assurez-vous que vous disposez de la dernière version de la base de données installée.
  3. Une fois les exemples de données prêts et les toutes dernières ressources de base de données installées, créez une flux de données simple qui lit les données d'un fichier, les traite à l'aide du stage que vous souhaitez optimiser et les écrit dans un fichier. Par exemple, si vous souhaitez tester les paramètres de performances de Validate Address, créez une flux de données composé de Read From File, Validate Address et Write To File.
  4. Définissez la taille de pool de ressource de base de données sur 1 :
    1. Ouvrez Management Console.
    2. Accédez à Ressources > Bases de données Spectrum.
    3. Sélectionnez la ressource de base de données à optimiser et cliquez sur le bouton Modifier .
    4. Dans le champ Taille de pool, saisissez 1.
    5. Cliquez sur OK.
  5. Définissez les instances d'exécution du stage sur 1 :
    1. Ouvrez le flux de données dans Enterprise Designer.
    2. Double-cliquez sur le stage que vous souhaitez définir de sorte qu'il utilise plusieurs instances d'exécution.
    3. Cliquez sur Exécution.
      Remarque : Tous les stages ne sont pas capables d'utiliser plusieurs instances d'exécution. Si aucun bouton Exécution n'apparaît au bas de la fenêtre du stage, cela signifie que le stage n'est pas capable d'utiliser plusieurs instances d'exécution.
    4. Sélectionnez Local et indiquez 1.
    5. Cliquez sur OK pour fermer la fenêtre Performances d'exécution, puis cliquez sur OK pour fermer le stage.
  6. Calculez les performances de base en exécutant le flux de données plusieurs fois et en enregistrant les valeurs moyennes pour chacun des éléments suivants :
    • Temps écoulé
    • Utilisation de l'UC
    • Utilisation de la mémoire
    Conseil : Vous pouvez utiliser la console JMX pour analyser les performances. Pour plus d'informations, reportez-vous à la section Analyse des performances à l'aide de la console JMX.
  7. Exécutez plusieurs instances simultanées du job, s'il s'agit d'un scénario qui doit être pris en charge. Enregistrez le temps écoulé, l'utilisation de l'UC et l'utilisation de la mémoire pour chaque scénario.
    Conseil : Vous pouvez utiliser un analyseur de fichiers pour exécuter plusieurs instances d'un job à la fois. Pour plus d'informations, reportez-vous à la section Déclenchement d'un flux avec un fichier de contrôle.
  8. Augmentez la taille de pool des ressources de base de données et le paramètre d'instances d'exécution des stages.
  9. Redémarrez le serveur.
  10. Exécutez de nouveau le flux de données, en enregistrant le temps écoulé, l'utilisation de l'UC et l'utilisation de la mémoire.
  11. Continuez à augmenter la taille de pool des ressources de base de données et les instances d'exécution des stages jusqu'à ce que vous commenciez à voir les performances diminuer.
  12. Si vous testez les performances de géocodage, répétez cette procédure en utilisant un seul pays et plusieurs pays.