modelisation d’application

Les applications sont devenues de plus en plus complexes et étudier le comportement et leur performance l'est d'autant plus. Surtout que beaucoup d'entre-elles comportent énormément de paramètres, typiquement, si on prend des produits comme web logic JBoss le manuel de tuning comporte des centaines de pages. D'où l'idée de modéliser les applications, c'est-à-dire d'avoir une vue un peu "stratosphérique" afin de mieux comprendre sur quels leviers agir.
Cette vision est bien sur une vision macro, mais on constate à travers les exemples relativement simples qu'elle a déjà un certain nombre de point d'observation et d'analyse sur lequel il faut porter son attention.
Ce modèle expose les relations entre les demandes générées par une charge de transaction et les ressources du système pour y faire face.
On pourra, bien sûr, la faire évoluer, soit en ajoutant d'autres éléments non pris en compte, soit en augmentant la précision du modèle.

TLDR;
* un délai dans une transaction vient de : un manque de ressource active ou un accès limité à une ressource active du à un manque de ressource passive.
* un manque de ressource passive est la cause d'une sous-utilisation de ressource active.
* dans un environnement majoritairement virtuel, les queues sont les indicateurs les plus fiables.

Construction du modèle

Pour construire notre modèle, on va avoir besoin d'un certain nombre d'éléments.

Les transactions

Elle caractérise notre requête utilisateur ! Si on imagine une usine de voiture, ou notre véhicule va parcourir la chaine, ici c'est notre transaction qui va visiter différent serveur et y passer du temps. On va trouver par exemple des choses comme :

  • login
  • rapport d'activité
  • une transformation de données
  • l'exécution d'une règle business
  • etc…

Les ressources

C'est tout ce qui va pouvoir être alloué pour la transaction. On va les classer en deux catégories : actives et passives.

En actives, on va trouver :

  • CPU
  • I/O
  • Network

En passives :

  • threads
  • espaces de stockage
  • allocation mémoire
  • les locks

De manière imagé on peut dire que les ressources actives exécutent la transaction et les transferts de données, tandis que les ressources passives fournissent un accès aux ressources actives que la transaction va consommer. D'un point de vus mesure, de façon général, une ressource active sera mesurer par un temps d'exécution tandis qu'un ressource passive sera plutôt une quantité (ex: nombre de connections, ou taille de mémoire …)

Nœud physique

Un nœud physique représente un serveur, une Appliance ou un élément de réseau.
Chaque un ensemble de ressources active et passive a une queue dans laquelle les transactions sont en attente de ressources disponibles.

Nœud virtuel

Un nœud virtuel c'est bien évidemment une machine virtuelle qui est représenté par un time-slice, ainsi une queue d'attente.

Nœud de ressources partagées

C'est un nœud physique qui possède des ressources partagées (ex: disques, CPU, etc.) à la différence d'un nœud physique.

La matrice ressource transaction

Avec une matrice on va définir pour chaque transaction les ressources active ou passive que qui vont être utilisé pour consommer le service.

matrice

matrice

L'utilisateur

L'utilisateur, évidemment, c'est la source de tout et notre but est de s'assurer qu'il y aura assez de ressources pour pouvoir les accueillir. Dans notre modèle, une transaction commence son voyage lorsqu'un utilisateur click sur un lien.
Au passage, on peut noter, que le temps entre deux clique d'un même utilisateur (souvent appelé think-time dans les logiciels) définit l'intensité du flux.

Exemples de modélisation

A partir de ces éléments, on peut définir notre modèle. Ici, on a composé deux modèles d'exemple de déploiement : un complètement physique et un complètement virtuel d'une application web Basic (aka 3 tiers). On va regarder un petit peu les différences que nos modèles peuvent nous montrer.
Dans un très classique 3 tiers on trouve : un serveur web, un serveur d'application et une base de données et on va supposer que 3 machines seront utilisées. Par ailleurs, on va dire que la transaction va commencer son voyage quand l'utilisateur va cliquer sur le lien et va donc suivre le cheminement à travers le serveur Web puis le serveur d'application, etc. La transaction va solliciter des ressources actives et passives telle qu'indiqué dans la matrice. A la fin, la réponse sera retournée à l'utilisateur. Le temps qui aura était passé dans tous les nœuds sera le temps de réponse. On peut d'ores et déjà voir que ce temps est à deux composantes : le temps de traitement par les ressources actives, et le temps d'attente d'accès aux ressources.

Cela donne le modèle physique suivant :
modele physique

Tandis que l'on aura un modèle virtuel comme ici :
modele virtuel

On observe rapidement une différence majeure entre le virtuel et le non virtuel.
* Le modèle virtuel a un ensemble de ressources partagées à travers les VMs.
* chaque VM ne peut utiliser ses ressources passive ou partagé que lorsque l'hyperviseur lui alloue un time-slice.

Analyse/Utilisation

Avec notre modèle, on va pouvoir, par exemple, regarder ce qui allonge le temps de réponse de nos transactions.
En regardant les schémas, on peut voir que pour traiter la transaction, nos serveurs ont besoin de CPU (!), et/ou que l'application à besoin de mémoire (ressources) pour son traitement. Que se passe-t-il si on manque de l'un de ces éléments ? Notre transaction va se retrouver dans une des queues à attendre ! Résultat, notre transaction va être retardée alors que le CPU n'est pas complétement utilisé par exemple.

Une famine de ressource passive entraine une sous-utilisation d'une ressource active.

Un délai peut-être causé par deux choses :
* un manque de ressource active.
* un accès limité à une ressource active à cause d'un manque de ressource passive.

En terme de production, cela veut dire que pour identifier les goulets d'étranglement, il va falloir monitorer non seulement les ressources active mais aussi les ressources passives. Et dans les ressources passive, il y a autant les éléments physiques "classiques" (mémoire, espace disque…) mais aussi des éléments plus logiciels (threads, connections pool, lock, les sémaphores etc.). On constate que pour pouvoir définir les ressources passives à monitoré cela demande des connaissances fines de l'interne de l'application et de son architecture.

allons plus loin…

Mais si on regarde le modèle virtuel cette fois, on va également constater d'autres effets.
On note, entre autre, l'apparition d'une nouvelle ressource critique : le time-slice que partagent toutes les VMs hébergées sur un même serveur.
Cet élément est structurant, pour qu'une VM puisse tourner il faut que son hyperviseur lui alloue une time-slice pour accéder à ses ressources physiques, ce qui n'est le cas que lorsque la ressource partagé demandé par la VM devient disponible !
De façon générale, un hyperviseur traite les VM comme des processus qui peuvent être stoppés et/ou reprises à n'importe quel moment. L'impact est que la VM ne peut plus compter sur un espace-temps linéaire et en conséquence les métriques de performances sont plus forcément représentatives !

Toutes métriques qui utilise un intervalle de temps (ex: utilisation CPU, nombre d'IOPS… en gros les compteurs les plus populaires) devient par conséquent non représentative

Que peut-on y faire ?

En se reportant à notre modèle, on perçoit que chaque ressource listé à une queue associé, et que pour avoir accès à sa ressource notre VM va devoir y attendre !

Les tailles de queues et les temps d'attente dans celle-ci sont les éléments majeurs qui définissent la performance de notre système car indépendant de toute notion de temps.

On peut aussi constater qu'une queue fournit l'indication d'un écart entre la demande (généré par notre charge de travail) et la disponibilité des ressources pour la satisfaire.

On peut aussi se poser la question de la pertinence de notre modèle de déploiement dans le cas virtuel. En effet, dans notre cas, la transaction va voyager à travers différentes VMs ce qui va augmenter le temps de traitement car chaque VMs va devoir attendre l'allocation d'un time-slice, les composants installés dans chaque VM venant en compétition des ressources partagées.
Imaginons donc le nouveau déploiement suivant : une application est installée entièrement dans une VMs dédié.
modele virtuel partagé
Le résultat implique qu'une transaction pourra être un durant un seul time-slice diminuant de fait son temps de traitement ! On aura toujours compétition sur les ressources partagé, mais, ici, entre applications et non plus au sein d'une même application.

Conclusion

Notre modèle, certes simplifié, nous permet déjà d'observer les gros points d'attentions et de mettre en évidence des différences entre physique et virtuel.

Bien sûr, en prenant en compte d'autres éléments dans sa construction, on pourra aller plus loin dans la modélisation de son comportement. D'autre part, parmi les évolutions, on peut aussi envisager d'aller chercher la théorie des queues, pour essayer de modéliser plus finement toutes les file qu'on l'on a dans le système.

Leave a Reply

You must be logged in to post a comment.