Archives mensuelles : novembre 2012

Modèle des performances d’un SI

Dans le cadre de cette problématique des performances du SI, comme dans d’autres où la complexité du SI pose en soit problème, enioka a la conviction qu’il est nécessaire de modéliser le SI pour mieux le comprendre, raisonner sur les questions ou problèmes rencontrés, et décider d’actions. Modéliser ne veut pas nécessairement établir un modèle
informatisé cathédrale du SI, mais d’abord d’avoir à travers un ou plusieurs modèles, des vues de synthèse d’un objet complexe permettant de l’analyser plus efficacement.

La performance est un domaine où la modélisation est une nécessité pour ne pas travailler au hasard, obtenir des résultats durables et bénéficier de bonnes pratiques.
Plusieurs points de vue de la modélisation sont à prendre en compte :

Modèle d’architecture

Pour étudier les performances d’un système, il faut avant toute chose en connaître l’architecture. On ne répare pas un appareil sans en avoir les plans. L’approche enioka sur ce point s’appuie sur deux grandes fondations : le modèle général des architectures et le modèle des services d’infrastructures (SOI : Service Oriented Infrastructure).

Le modèle général des architectures, structurés autour de quatre points de vue :

  • Modèle fonctionnel des services offerts par la solution, l’objectif de ce point de vue est de cerner de manière synthétique les services (avec les exigences associées)
    que rend l’architecture à ses différents utilisateurs/clients/administrateurs.
  • Modèle logique du fonctionnement : l’objectif de ce point de vue est de détailler le fonctionnement de la solution, et de comprendre comment chaque composant est
    sollicité pour rendre chaque service. C’est ce modèle qui permet d’assurer le lien entre l’usage des services et l’usage des ressources.
  • Modèle physique des ressources affectées aux fonctions : l’objectif de ce point de vue est de décrire précisément les ressources allouées et les éléments clés de
    leur configuration (en termes quantitatifs). C’est ce modèle qui porte les « capacités » des ressources de la solution en termes de puissance et de rapidité de traitement notamment.
  • Modèle des opérations destiné à décrire comment est opéré la solution. Dans certains sujets de performances, la clé réside en partie dans les capacités de
    pilotage données aux opérations et/ou à la délégation de certains travaux à l’ « usine » des opérations en lieu et place des utilisateurs finaux.

Ce modèle d’architecture s’appuie sur le modèle des services d’infrastructure, le modèle « SOI » (Service Oriented Infrastructure) qui définit les différentes couches de service que l’on retrouve de manière standard dans toutes les solutions. Ce modèle sert d’accélérateur dans l’analyse et la conception des architectures SI (et dans des DSI
industrielles, de rationalisation), et dans le contexte précis à normaliser les éléments clés de contrat de service et de moyens de pilotage associés de ces services. Ce modèle s’appuie notamment sur plusieurs couches de services :

  • couches des infrastructures physiques et des ressources : services de stockage, services de calcul, etc.
  • couches middleware : services base de données, serveur d’application, services d’intégration, etc.
  • couches applicatives génériques : services de portail, de reporting, éditique, services d’annuaire, etc.

Modèle d’activité métier

L’objectif est de caractériser l’usage de la solution et finalement de définir des unités d’œuvre qui permettront de tailler la solution. Le modèle le plus primitif se limite le plus souvent à estimer le nombre d’utilisateurs nommés, voire connectés à l’application. Mais au delà de ce modèle trivial, il convient de modéliser, avec une finesse plus ou moins grande selon les objectifs poursuivis :

  • les données en termes de stocks versus flux. Autrement dit les données accumulées au cours du temps (en fonction de la rétention des données) et les taux d’accroissement par jour ou par mois de ces principaux stocks (nombre de clients ou fournisseurs créés, nombre de factures émises, etc).
  • les utilisateurs, non seulement en termes de  nombre mais en les caractérisant par profils principaux (comme acheteurs, chefs d’affaire, comptables) et en évaluant leur niveau d’activité (habituellement on définit des profils normatifs de type utilisateurs lourds/moyen/léger) qui permet d’estimer leur niveau de sollicitation combiné.
  • l’activité de ces profils d’utilisateurs doit en outre être caractérisée par un profil de charge qui permet de mesurer leur usage des différents services de la solution : usage des différentes transactions, des restitutions ou des traitements qui peuvent être déclenchés par les utilisateurs. Cet usage est caractérisé par un nombre d’exécutions par unité de temps.
  • les principaux traitements à effectuer dans le cadre du plan batch, en identifiant les facteurs principaux dimensionnants de ces traitements (nombre de factures  traitées, nombre de ventes, etc).

Modèle de temps de réponse

Un temps de traitement est la composition de différents temps élémentaires. Cette décomposition découle directement du modèle d’architecture. Dans les architectures n tiers modernes, ce « temps » est en fait décomposé en multiples tronçons qui ne sont pas toujours simples à démêler : temps du navigateur, temps réseau WAN, temps  infrastructures de sécurité, temps frontal web, temps serveur d’application et  d’intégration, temps bases de données, temps stockage, etc. Le temps de réponse vu de l’utilisateur est par ailleurs rarement la simple somme des temps de chacun de ces tiers. La vision claire de cette décomposition et des éléments les prépondérants dans le temps global est indispensable pour guider les travaux d’analyse et d’optimisation.

Modèle d’usage des ressources

Le lien entre l’activité métier et l’usage des ressources (et indirectement du temps de  réponse) est un lien complexe. Il peut heureusement sous réserve d’hypothèses à valider  (notamment de plages d’usage) souvent être considéré comme lié « linéairement » à certaines unités d’œuvre qui caractérisent l’activité métier. Néanmoins les différentes contributions de chaque type d’activité à l’usage des ressources restent souvent délicates à discerner entre elles. Par exemple un utilisateur métier moyen actif consomme par période de référence (par exemple 10 minutes) un certain volume de mémoire sur chaque tiers, un certain nombre de secondes CPU sur chaque tiers, un certain nombre d’IO  logiques et physiques et une certaine quantité de bande passante sur le réseau.
Modèle des coûts SI

En filigrane de cette réflexion, il y a toujours de manière implicite la notion de coûts. Coût des ressources (et notamment de leur augmentation, avec les effets de seuil éventuels  associés), coût des développements à réaliser pour corriger/améliorer la solution, coût des équipes en charge de détecter et caractériser les problèmes de performance, coût induit sur les utilisateurs du fait de performances insuffisantes.

Ces différents modèles seront abordés dans des articles plus spécifiques à chacun d’entre eux et à leur usage dans le contexte de problématiques de performances.