Responsabilité de l’ingénieur face à son environnement

UC- 3 : Utiliser et paramétrer les objets connectés.

AGUESSE JUSTIN | ING 2 | FISA 2019-2020

 UC- 3 : Utiliser et paramétrer les objets connectés.

L’objectif de mon UC est d'offrir au résident la possibilité de manipuler ses objets connectés.
Ce cas d’utilisation est un pilier dans le projet puisqu’il constitue la base de l’application pour
l’utilisateur et son implémentation est cruciale pour tous les autres cas attendu. En effet, la
description des objets ainsi que leurs utilisations est fonctionnement nécessaire pour le
résident dans le cadre de la modification de leurs paramètres mais aussi dans la gestion du
monitoring par le personnelle encadrant.

Pour présenter une analyse de performance et d’impacte énergétique de mon UC, je vais
m’attarder sur la partie qui concerne exclusivement les objets et leurs manipulations en
observant différents paramètres. Le file directeur de ma présentation sera linéaire par
rapport aux exécutions qu’entraine la manipulation de l’interface.

Pour construire mon analyse je vais utiliser deux technologies différentes que je vais
présenter dans leurs implémentations ainsi que dans le cadre de leurs utilisation.
Les analyses se feront de manière principalement visuelles avec un travail par graphique
des résultats obtenues.

La performance du système peut s’analyser sous différentes forme et pour essayer d’être le
plus précis possible, je vais développer un maximum d’informations en essayant toujours les
ramener dans un contexte d’utilisation.
De la même manière, l’étude de la charge supporté par le système se fera par le biais
d’indicateurs logiques. Par exemple une étude de charge sur 10 000 concurrents n’a pas de
sens dans le cadre de test a réalisé sur notre système dont la charge maximum est borné
par le nombre d'utilisateur de la maison de retraite dans le pire et le meilleur des cas.

Enfin, je décide pour la construction de l’analyse de mon cas d’utilisation d’analyser toujours
en parallèle la consommation énergétique de mon système en lien avec les stimulations de
performance que je vais lui faire subir.
1 - Structure de mon UC

Pour analyser mon UC, je vais rapidement repartir sur la structure en base de donnée qui la
concerne.

La structure est relativement classique avec une représentation en flocon de neige. L’outil
Spring a permis d'optimiser la construction de cette structure de données avec une forme de
“rétro engineering”. En effet, après une première phase de conception de l’esprit,
l’implémentation en base est complètement généré automatiquement par Spring qui, grâce à
des annotations permets de liés directements les objets en base de donnée et les objets
conceptuels dans le code.
L’analyse de mon système se fera sur la ligne tracé par le diagramme de classe
participantes :

Ainsi, je commencerais par une analyse du front (IHM) qui représente la moitié de l’étude de
notre service. Nous avons décidé de partir sur des technologies responsives reposants sur
des modules plutôt lourd et complets.Pour construire mon UC je me suis basé sur
l’utilisation de module Angular, notamment ceux de la librairie “Matérial” et j’aimerai observer
la charge que représente leur manipulation sur ma partie consacré à la manipulation des
objets. Ensuite, cette analyse est pertinente dans le cadre ou le service offert au client
(notamment les résidents) repose essentiellement sur la capacité qu’ils auront de manipuler
leurs objets connectés.

2 - Outils d’analyse

Pour effectuer des analyses de performance de mon UC, il fallait que je trouve une manière
de simuler d’une part l’HTML et tous les modules annexes pour la partie Front et d’autres
part tous les services offert par le back. Pour avoir du sens cette analyse devait se faire
sous différent niveaux de stresse de mes serveurs pour observer leur comportement en
terme de performance et de consommation d’énergie.
 a - Selenium

Selenium est un framework de test informatique développé en Java. Il permet d’interagir

avec différents navigateurs web de même que le ferait un utilisateur de l’application. Il entre
ainsi dans la catégorie des outils de tests dynamiques facilitant les tests fonctionnels.

Composition du main :

En terme d’étape, on observe bien l’initialisation de l’Host qui correspond ici à l’adresse de
notre firewall. La redirection par port se fait immédiatement à la connexion pour ensuite
rediriger les requêtes vers l'environnement de production.
Afin de construire une simulation de charge j’ai construit plusieurs scénarios voué à interagir
avec chacun de mes objets :

Leurs conception est relativement simple et ne mérite pas d’être présenté ici.

Enfin j’ai construit un pôle de Thread qui permettent de simuler un grand nombre d’utilisateur
directement sur ma machine.

L’intérêt de sélénium est donc dual ici :

- Vérifier la fiabilité de l’interface et la latence entre les différents appels

- Stimuler le back par appel des fonctions implémentées dans les Controller et qui
constituent les web service de mon cas d’utilisation (un par controller).
Le thread est générique et est configuré pour constituer un profil particulier à sa création.
Les objets appelés sont donc différents pour chaque utilisateur (ici représenté par un
thread).

Enfin, pour avoir une idée précise du temps j’ai utiliser des fonctions java qui indique à la
milliseconde prêt la durée d'exécution du programme, ce qui me permet de récupérer sur les
serveurs concernés les zones d’impactes précise de mes simulations.

-
 - b : Siege - HTTP/HTTPS stress tester

J’ai découvert cet outil après Sélénium et son utilisation est complémentaire. Siege est un
utilitaire de test et d’analyse comparative de charge HTTP multithread. Il a été conçu pour
permettre aux développeurs web de mesurer les performances de leur code sous la
contrainte. Il permet de touche un serveur web avec un nombre configurable d’utilisateur
simulés simultanément. Ces utilisateurs vont placer le serveur Web “en état de siège”. Les
mesures de performances incluent le temps écoulé, le temps total des données transférées,
le temps de réponse du serveur, son taux de transaction, son débit, sa simultanéité et le
nombre de fois qu’il est retourné OK. Ces mesures sont quantifiées et rapporté à la fin de
chaque série.

Siege a globalement trois modes de fonctionnement :

- La régression (avec une invocation par bombardement)
- La simulation sur internet
- La force brute.

Nous nous intéresserons principalement dans ces analyses à la simulation ainsi que la
régression.

On a également le détail de ces échanges dans un fichier de log dont la pertinente est à
nuancer car on a pas le détail des requêtes :
Lexique des termes :

Transactions :
Le nombre d'accès au serveur. Dans l'exemple, 100 utilisateurs simulés [-c 100] ont chacun
frappé le serveur 5000 fois [-r5000], soit un total de 500 000 transactions. Il est possible que
le nombre de transactions dépasse le nombre de hits planifiés. Le siège compte chaque
serveur frappé par une transaction, ce qui signifie que les redirections et les défis
d'authentification comptent pour deux hits, pas un. À cet égard, le siège suit la spécification
HTTP et imite le comportement du navigateur.

Availability :
Il s'agit du pourcentage de connexions socket traitées avec succès par le serveur. C'est le
résultat des échecs de socket (y compris les délais d'attente) divisé par la somme de toutes
les tentatives de connexion. Ce nombre n'inclut pas les erreurs de serveur de niveau 400 et
500 qui sont enregistrées dans les «transactions ayant échoué».

Elapsed time :
La durée de l'ensemble du test de siège. Ceci est mesuré à partir du moment où l'utilisateur
invoque le siège jusqu'à ce que le dernier utilisateur simulé termine ses transactions.

Data transferred :
La somme des données transférées à chaque utilisateur simulé de siège. Il comprend les
informations d'en-tête ainsi que le contenu. Parce qu'il comprend des informations d'en-tête,
le nombre signalé par siège sera plus grand que le nombre signalé par le serveur.

Response time :
Temps moyen nécessaire pour répondre aux demandes de chaque utilisateur simulé.

Transaction rate :
Le nombre moyen de transactions que le serveur a pu gérer par seconde, en résumé:
transactions divisées par le temps écoulé.

Throughput :
Le nombre moyen d'octets transférés chaque seconde du serveur à tous les utilisateurs
simulés.

Concurrency :
Le nombre moyen de connexions simultanées, un nombre qui augmente à mesure que les
performances du serveur diminuent.

Successful transactions :
Le nombre de fois que le serveur a répondu avec un code retour <400.
Failed transactions :
Nombre de fois où le serveur a répondu avec un code retour> = 400 plus la somme de
toutes les transactions de socket ayant échoué, ce qui inclut les délais d'expiration de
socket.

Longest transaction :
La plus grande quantité de temps prise par une seule transaction, sur toutes les
transactions.

Shortest transaction :
La plus petite quantité de temps prise par une seule transaction, sur toutes les transactions.

Note :

Cette outils de siege, est notamment utilisé pour réaliser des attaques par déni de service
(Dos attack) qui constitue une attaque ayant pour but de rendre indisponible un service, et
d’empêcher ainsi les utilisateurs légitimes de l’utiliser.
Cette attaque peut être réaliser de différente façon, et l’outil siege en fait parti car il va
permettre d'inonder le réseau et en empêcher son fonctionnement.
Ici évidemment le but n’est pas de faire tomber le serveur, mais lors de la dernière phase
d’analyse sur les tests de charge critiques, nous tenterons de pousser le serveur a son
maximum pour observer son comportement sur un niveau de stresse très élevé. On pourra
ainsi en multipliant les concurrents observer le maximum de charge qu’il est capable de
supporter ainsi que la plage de temps correspondantes.

3 : Analyse :
Pour effectuer cette analyse, a chaque fois, un indice de temps sera précisé qui
correspondra à la plage temporelle sur laquelle sera réalisé mon test. A chaque fois,
l'échantillon sera représentatif.

a - Charge nulle

A charge null, les performances de notre système sont optimale sur tous les aspects.

Indice de temps : Pour analyser mon cas d’utilisation à charge nulle, je suis partie de de
l’observation des données sur un début de journée. En effet, le projet étant manipulé par les
développeurs durant la journée, je voulais avoir un indice le plus fiable possible.
L’analyse a charge nulle est pertinente parce qu’elle permet de donner une base de
performance et de consommation énergétique. Toutefois, dans le cadre de mon UC, cette
thématique n’est pas très pertinente, car il n’y a pas de processus qui tourne en back sans
action utilisateur.

Résultat attendu :
- Le taux d’utilisation du CPU devrait être proche de 0
- L’alimentation de la machine devrait être proche de 0
Résultats observés :

La consommation électrique est en moyenne d’1,8 joules sur un intervalle observé de 5

minutes. La moyenne d’utilisation est quant à elle nulle évidemment pour des raisons
d'inactivité. Cette valeur peut être relativisé car l’outil de récupération de ces valeurs
(VSphere) n’indique pas de variation de Watt si elle n'excède pas 1 watt au minimum.
On peut donc en conclure que la consommation énergétique sur le serveur lié à l’utilisation
est contenu entre 0 et 1 soit une valeur négligeable suivant l’unité. Cette valeur étant
évidemment à redonder sur chaque machine de notre architecture.

Note : On notera ici que les valeurs sur la machine ne back sont absolument identique que
celles observées sur la machine de front.
Pour ce qui est des performances, les résultats attendue sont bien ceux observés. Les
légères variations que l’on observe sont une résultante de l'activité d’autres UC qui tournent
perpétuellement sans actions utilisateurs.

Le serveur BACKEND de l’environnement de production, sur les heures d'inactivité du

service, observe une utilisation quasiment nulle du CPU qui est rythmé par un thread en
back indépendant de mon cas d’utilisation.
L’utilisation en mégahertz permet de montrer cette rémanence d’actions en mettant en
valeur les fréquences d’exécution.

On peut donc conclure que sur une charge nulle du service, l’impacte énergétique est
minime en terme de consommation électrique, et l’évaluation des performances est stabilisé
à 0 pour les observations futures.

b - Charge usuelle

A partir des observations précédente, on peut avancer que nos serveurs non stimulés ont
une attitude normale avec une utilisation du CPU proche de 0 et une alimentation de la
machine également proche de 0. Les performances ne sont pas ici mis en exergue, mais
cette stabilité va pouvoir souligner l’application d’une charge sur le serveur.

Pour tester cette charge usuelle je vais simuler grâce à mon programme Selenium une
activité de plusieurs résident sur un laps de temps.
Attention, le but ici n’est pas de générer une charge extrême, mais seulement d’observer
causées par l’utilisation du service.