Configuration des performances de Point-In-Polygon

Lorsque vous créez une solution point-in-polygon, il existe certaines modifications de configuration spécifiques que vous pouvez apporter aux ressources du serveur et de la base de données et qui affectent les performances du serveur Spectrum. Suivant que vous utilisez le stage Centrus (Legacy) Point In Polygon ou le stage Query Spatial Data, le mode de configuration de Spectrum pour améliorer les performances varie.

Configuration des ressources du serveur pour le stage Query Spatial Data Le stage Query Spatial Data utilise le composant spatial distant du module Location Intelligence. Il est important de configurer les ressources de l'ordinateur en fonction des processus du stage et du serveur. Lorsque vous exécutez des opérations point-in-polygon à l'aide du stage Query Spatial Data, assurez-vous que le nombre de cœurs de l'ordinateur du serveur est disponible pour le composant spatial distant. Lorsque vous utilisez un stage pour le traitement, il est important que le nombre de threads du stage Query Spatial Data soit égal au nombre de cœurs de l'ordinateur. Pour modifier ceci, modifiez les paramètres d'exécution du stage Query Spatial Data lorsque vous l'utilisez dans Enterprise Designer. Pour plus d'informations sur la façon d'optimiser les performances de Spectrum et des composants distants, reportez-vous à la section Réglage précis des performances.

Remarque : Si le serveur doit être disponible pour les autres types d'opérations, la mise à disposition de tous les cœurs pour le composant spatial distant peut priver ces processus de ressources.

Configuration de la taille de pool et du cache des ressources de base de données Centrus (stage Legacy Point In Polygon). Lorsque vous créez vos ressources de base de données Centrus dans Spectrum (via Management Console), il est important de configurer les champs Taille du cache et Taille du pool au mieux en fonction de la configuration de vos serveurs.

Dans le champ Taille du pool, définissez le nombre maximal de requêtes simultanées que cette base de données doit gérer. La taille de pool optimale varie et des tests doivent être réalisés avec différentes combinaisons de taille de pool et de taille de cache pour obtenir les meilleures performances. 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 prendre en compte le nombre d'instances d'exécution indiquées dans le flux de données pour les stages accédant à la ressource de base de données. Considérez par exemple un flux de données disposant d'un stage (Legacy) Point In Polygon configuré pour utiliser une instance d'exécution. Si vous définissez la taille de pool de la base de données sur quatre, 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 ressource de base de données. Cependant, si vous souhaitez augmenter le nombre d'instances d'exécution à quatre, vous pouvez voir une amélioration de performances dans la mesure où il y aurait quatre instances de Point In Polygon accédant à la ressource de base de données simultanément, utilisant ainsi le pool entier.

Le champ Taille du cache détermine la quantité de mémoire à utiliser pour mettre les données en cache. En général, plus le cache est volumineux, meilleure est la performance.