Comment optimiser les requêtes Symbolic volumineuses
(Traduction du document original anglais)
Description
La requête de lecture/écriture Symbolic permet d'effectuer des requêtes comportant jusqu'à 128 symboles.
L'utilisation d'un grand nombre de symboles peut provoquer un ralentissement de l'application. Il existe plusieurs règles permettant d'améliorer la vitesse d'exécution de l'application en réduisant le nombre de requêtes internes.
L'objectif de cette rubrique est de vous aider à créer un espace de noms cohérent et à utiliser des requêtes Symbolic de manière efficace.
Traitement d'une requête Symbolic
Les requêtes Symbolic permettent d'utiliser des symboles plutôt que des adresses pour traiter les données de l'automate. Ce système de requête utilise l'espace de noms du module pour résoudre les adresses. Une fois les adresses connues, un processus d'optimisation trie les adresses par type (bits de sortie, registres) et les classe par ordre croissant.
Les adresses triées doivent être regroupées dans un bloc cohérent pour réduire le nombre de requêtes envoyées à l'UC. Le graphique ci-dessous présente les trois étapes d'optimisation d'une requête Symbolic :
Méthode d'optimisation
Pour optimiser une requête Symbolic volumineuse, regroupez les symboles comme suit :
Etape
Action
1
Regroupez les symboles par type : ne mélangez pas les bits de sortie et les registres.
2
Si possible, classez les symboles dans l'ordre croissant.
3
Essayez de définir des blocs de symboles (c'est-à-dire, des adresses de symboles contiguës). Ces blocs seront traités dans une seule requête de bas niveau.
Exemple d'optimisation
Prenons un fichier d'espace de noms relativement simple :
|STATION:0.0 16 |Bit_mem1|%M0|0|0|1|1|1|false |Bit_mem2|%M1|0|0|1|1|1|false |Bit_mem3|%M2|0|0|1|1|1|false |Bit_mem4|%M4|0|0|1|1|1|false |Bit_mem5|%M5|0|0|1|1|1|false |Bit_mem6|%M6|0|0|1|1|1|false |Engine_Brake_lvl|%MW0|0|0|4|1|1|false |Engine_Brake_dsk|%MW1|0|0|4|1|1|false |Engine_gauge_1|%MW2|0|0|4|1|1|false |Engine_gauge_2|%MW3|0|0|4|1|1|false |Engine_gauge_3|%MW4|0|0|4|1|1|false |Engine_gauge_4|%MW5|0|0|4|1|1|false |Engine2_Brake_lvl|%MW100|0|0|4|1|1|false |Engine2_Brake_dsk|%MW101|0|0|4|1|1|false |Engine2_gauge_1|%MW102|0|0|4|1|1|false |Engine2_gauge_2|%MW103|0|0|4|1|1|false |Engine2_gauge_3|%MW104|0|0|4|1|1|false |Engine2_gauge_4|%MW105|0|0|4|1|1|false 0 1 false

Il contient des valeurs pour deux moteurs (engine et engine2).
Il contient également des valeurs booléennes (Bit_mem).
Si vous créez une requête pour chaque symbole dans l'ordre de l'espace de noms, vous recevrez une requête SOAP avec 16 valeurs. Comme ces valeurs sont triées par type et par adresse (en ordre croissant), l'optimisation ne va traiter que des blocs d'adresses. Dans le cas présent, nous avons trois blocs :
Trois requêtes de bas niveau sont envoyées à l'UC.
Si l'utilisateur final demande cinq symboles dans une requête SOAP : Engine_gauge_3, Engine_gauge_1, Bit_Mem1, Engine2_gauge_3, Engine2_gauge_1.
Etape
Action
1
Dans la mesure où les symboles sont mélangés, la première étape d'optimisation consiste à trier les bits de sortie et les registres.
2
Au cours de cette étape, les symboles de même type sont triés par adresse. La requête SOAP n'étant pas correctement ordonnée, les données doivent être traitées pendant cette étape.
Au terme de cette étape, nous disposons de deux tableaux : un avec un bit de sortie et un autre avec quatre registres :
3
Cette étape doit permettre de trouver les adresses contiguës. Puisqu'il n'y en a aucune, nous avons cinq blocs composés d'une adresse.
Résultat final : cinq requêtes de bas niveau ont été envoyées à l'UC.
En bref
Lorsque vous faites un usage intensif (en nombre et en temps) des requêtes Symbolic, respectez les règles suivantes :