Les problèmes de performance disques peuvent être comparés aux problèmes de performance réseau en ce que leur charge est mesurée grâce à deux caractéristiques comparables : le débit et le temps d'accès.

Plus un disque aura un débit important, plus il sera capable d'alimenter le système avec de gros volumes de données . Plus un disque aura un temps d'accès court, plus il sera capable de fournir rapidement des données atomiques à l'unité de traitement.

Principe de gestion de la mémoire virtuelle

Lorsqu'un processus alloue un nouvel espace mémoire, le système d'exploitation va rechercher un ou plusieurs emplacements libres (pages) pour l'y affecter. Si l'espace restant est insuffisant, le système va alors réquisitionner une ou plusieurs pages déjà allouées pour y installer les nouvelles données. Les données remplacées restent alors disponibles uniquement sur le disque. Le système choisit les pages les moins souvent accédées pour les remplacer, et partant du principe que seule une partie de la mémoire allouée est réellement utilisée, cette opération reste transparente au niveau des performances.

En fonctionnement normal un système permet aux processus d'allouer plus de mémoire qu'il n'en dispose réellement. Ce fonctionnement s'appelle la mémoire virtuelle et est basé sur le dispatching des pages mémoires allouées sur la mémoire réelle et un espace disque dédié. De cette manière, les pages mémoires non utilisées sont stockées sur le disque, libérant autant d'espace en mémoire pour celles réellement utilisées.

Cette technique qui permet de s'affranchir de la limite physique de la mémoire peut être à l'origine de la dégradation des performances lorsqu'un grand nombre de pages stockées sur le disque doit être rapatrié en mémoire ou encore lorsque la rotation des pages entre la mémoire et le disque devient trop importante. Cette situation se produit lorsque le nombre de pages mémoire actives s'approche ou dépasse la taille mémoire réelle.

Un système d'exploitation a pour rôle essentiel de permettre le partage des ressources d'un serveur entre tous les processus utilisateurs. Les ressources qui nous intéressent ici sont les processeurs, les disques et la mémoire.

La charge CPU peut augmenter et être à l'origine d'un problème de performance pour deux raisons :

• Le nombre de processus à gérer augmente, ajoutant à la fois du temps de calcul (les travaux utilisateur) et du temps système (le temps utilisé par le système d'exploitation pour partager la ressource processeurs entre tous les processus). C'est le cas dans les applications où un utilisateur connecté provoque le lancement d'un processus serveur.
• Le nombre de processus reste stable mais la charge de calcul augmente. Il peut s'agir dans ce cas de traitements plus lourds lancés par les utilisateurs en nombre constant, ou lorsqu'un moniteur transactionnel gère le partage de ressources, ou la combinaison des deux.

]]> luc.demaret@gmail.com (Luc Démaret) Mon, 05 Mar 2012 10:48:55 +0000 http://www.envols.eu/memos/generalites/18-outils-maintenance-performance-i http://www.envols.eu/memos/generalites/18-outils-maintenance-performance-i 1/ Une bonne approche pour débuter une étude de transaction longue

Confronté à un problème de transaction longue, l'idéal est de chercher à l'isoler à l'aide d'un sniffer réseau du type wireshark (anciennement ethereal) installé sur le poste client.

Un sniffer est un outil capable de tracer et d'analyser les échanges réseau sur une période donnée. L'intérêt d'un tel outil dans le cadre d'une étude de performance est qu'une fois la transaction  problématique isolée, on sera capable à la fois de reconstituer le nombre d'échanges réseau qu'elle génère entre le client et le back-end, de mesurer le volume échangé, le temps de réponse unitaire de chaque appel et ainsi d'isoler le ou les points problématiques.

Une des causes aisément identifiable vient de la charge des composants de l'architecture technique (serveurs, SGBD, réseau, baie disque etc…). En situation de forte demande, un ou plusieurs de ces composant se trouve saturé et ne peut plus répondre dans les délais habituels.

Il apparaît que la croissance du temps de réponse n'est pas une fonction linéaire de la charge (deux fois plus de charge ne double pas les temps de réponse). En effet, pendant un temps, augmenter la charge affectera peu le temps de réponse moyen (zone d'utilisation normale du composant), mais passé un seuil (le point d'inflexion de la courbe), les temps de réponse du composant touché vont croître de plus en plus rapidement rendant le service quasi inopérant. Sur l'illustration ci-dessous on distingue aisément la zone d'utilisation normale du composant, la zone critique ou de faibles variations de charge entrainent de fortes fluctuations du temps de réponse et la zone où le composant peut-être considéré comme inutilisable car délivrant des temps de service trop longs (risque de timeout des autres composants).

Le temps d'acheminement est constitué de la somme des temps consommés sur le réseau pour acheminer les données ou appels d'un tiers sur l'autre.

Si nous reprenons notre architecture classique client / serveur d'application / serveur de base de données, la validation de la transaction fonctionnelle sur le poste client va envoyer une ou plusieurs demandes au serveur d'application, qui va à son tour déclencher l'exécution de une ou plusieurs requêtes SQL sur le serveur de base de données, qui renverra des données pour traitement, que le serveur d'application mettra en forme pour renvoyer à son tour sur le poste client.

]]> luc.demaret@gmail.com (Luc Démaret) Sun, 12 Feb 2012 15:30:16 +0000 http://www.envols.eu/memos/generalites/15-temps-traitement-long http://www.envols.eu/memos/generalites/15-temps-traitement-long 1/ Les temps de traitement longs

Quand nous parlons de transaction, nous parlons de l'unité fonctionnelle vue par l'utilisateur : il entre ses données et valide son choix, puis attend de pouvoir reprendre la main pour continuer son travail.

Il est relativement rare d'être confronté à une transaction longue dépendant uniquement d'un seul traitement long. Souvent, une transaction utilisateur est composée de nombreuses tâches exécutées sur différentes unités, comme par exemple un programme ou un JavaScript sur le poste client, un traitement .NET sur le serveur d'application ou encore les requêtes SQL générée par le traitement sur le serveur de base de données. L'un ou l'autre de ces traitements peut être lent, ou peut consister en une répétition (une boucle) de traitements unitaires rapides, mais dans tous les cas, les temps d'exécution cumulés représentent une fraction non négligeable du temps total de la transaction.

La première étape de l'étude d'un problème de performance est sa qualification, qui revient à décrire précisément les symptômes dans leur localisation spatiale ou temporelle, leur intensité, leur reproductibilité.

Localisation spatiale et temporelle : Où et Quand ?

Une transaction peut être (ressentie comme) longue à certains moments de la journée ou dans certains sites utilisateur. Restreindre son périmètre permet d'orienter les recherches ultérieures. Si par exemple tous les temps de réponse s'allongent démesurément aux mêmes heures de la journée et pour tous les utilisateurs, on s'orientera plutôt sur un problème de surcharge d'un ou plusieurs composants de l'infrastructure qui pourrait être due à une activité concurrentielle trop importante ou à une opération lourde récurrente (traitement batch de calcul de statistiques qui écroule le système).
En revanche, la localisation du problème sur une partie des sites utilisateurs pourrait amener à étudier un éventuel problème de réseau ou encore l'utilisation de données particulières spécifiques à ce site qui pourrait laisser subodorer un problème applicatif ou d'indexation de base de données.

]]> luc.demaret@gmail.com (Luc Démaret) Tue, 07 Feb 2012 10:38:19 +0000 http://www.envols.eu/memos/generalites/13-performance-applicative http://www.envols.eu/memos/generalites/13-performance-applicative La performance applicative, qu'est-ce que c'est ?

C'est une spécialité de l'architecture technique, généralement coté maintenance technique, dont l'objectif est d'analyser les problèmes de performance remontés par les utilisateurs afin d'en établir la cause et rédiger les préconisations pour les résoudre.

Les problèmes de performance

Un problème de performance est remonté par les utilisateurs quand un temps de réponse - ou d'exécution s'il s'agit d'un batch - dépasse la durée stipulée au cahier des charges, ou est simplement ressenti comme trop long. A noter qu'en mode transactionnel, un temps de réponse de plus de 2 secondes est ressenti comme trop long.

]]> luc.demaret@gmail.com (Luc Démaret) Sun, 05 Feb 2012 13:41:37 +0000