Paramètre "general/max_threads" de HR Query

A compter de HRv7.20.6, les paramètres de configuration "batch_query/max_running_threads", "batch_editing/max_running_threads" et "tp_query/max_running_threads" (paramètres techniques du module "HRD Query" dans l'objet topologie "HRS") ont été remplacés par un unique paramètre "general/max_threads" (dixit le PDF Editeur listant les évolutions de la release).




Ce paramètre définit le nombre maximal de tâches (sélection / extraction / mise en forme) que le serveur de query peut traiter simultanément.

Sa création est associée à un changement dans les mécanismes de parallélisation du dispatching des XML Data pour les états PDF, HTML, CSV pour tirer parti de toute la puissance de calcul des machine multi-cœurs.

La valeur de ce paramètre dépend des capacités physiques de la machine ainsi que du quota de puissance qui lui est alloué. Par défaut,la valeur de ce paramètre vaut "0" ce qui signifie "Autant de threads que la machine comporte de processeurs". Dans le cas contraire c'est le nombre spécifié qui sera pris en compte... En toute logique sur une machine hébergeant plusieurs environnements il faut limiter ce nombre.

Un second paramètre "general/threading_strategy" apparait. Il prend deux valeurs :

• "performance" (valeur par défaut - utilisera le maximum de threads possible) 
• "latency" (utilisera moins de threads pour pouvoir mieux répartir la puissance)

Dans le cas d'une valeur "performance", si une requête qui génère beaucoup de tâches parallèles est soumise en premier, celle-ci va monopoliser le serveur de query pendant tout le temps de son exécution. Les requêtes suivantes devront patienter en file d'attente.

A l'inverse si le paramètre est positionné à"latency", les threads seront alloués pour équilibrer les performances des tâches en parallèle. Ce mode a l'inconvénient de moins tirer bien parti des capacités de calcul de la machine. Sur un traitement particulier l'écart peut atteindre 25 à 30% - prévient l'éditeur.