Editorial


La valeur du temps de réponse

Traduit par : Stéphane FAURE

Introduction

Cet article est la traduction d'une étude, déjà ancienne, publiée en novembre 1982 par : Mais les conclusions de cette étude sont assez générales pour être encore valables, voire même d'une actualité aiguÙ dès lors que l'apparence des applications semble prévaloir sur toutes les autres considérations fonctionnelles, y compris les performances. L'article original peut être consulté sur Internet à l'adresse :   http://www.s390.ibm.com/canada/evrrt

Préambule

Quand un utilisateur peut se servir d'une application interactive sans qu'aucun des deux n'ait à attendre l'autre : Peu de systèmes informatiques sont configurés pour de tels temps de réponse interactifs (3). Peu de responsables informatique connaissent l'impact et les enjeux de telles configurations. En fait, une légende perdure qui voudrait qu'un temps de réponse relativement élevé (c'est-à-dire mauvais), de l'ordre de deux secondes, soit acceptable à cause du délai de réflexion nécessaire entre deux saisies. Mais les études sur l'impact du temps de réponse indiquent que cette vieille théorie n'est pas née de l'observation des faits qui montrent que la productivité augmente proportionnellement plus vite que le temps de réponse ne diminue.

Vocabulaire

Transaction
Une transaction (voir la Figure 1) consiste en la saisie d'une commande sur un terminal jusqu'à la réponse du système. C'est l'unité de mesure fondamentale pour les applications interactives. Elle peut être décomposée en deux intervalles de temps distincts :

Temps de réponse utilisateur
Le temps de réponse de l'utilisateur est le délai entre la dernière réponse du système et la saisie d'une nouvelle requête.

Temps de réponse système
Le temps de réponse du système (symbolisé par TdRS dans la suite de cet article) est le délai entre la saisie d'une requête et son exécution complète par la machine. Il se divise lui-même entre :

Figure 1. Décomposition d'une transaction



* Figure 24tdr1 not displayed.


Présentation

Quand les systèmes interactifs commencèrent à se banaliser, des psychologues défendirent l'opinion qu'une attente de deux secondes était le maximum que devrait avoir à supporter un utilisateur. Pour les développeurs et les architectes de systèmes, ce délai devint un objectif à atteindre... et, à cette époque, ce n'était pas chose aisée, Le paradygme voulant que l'utilisateur utilise le TdRS pour réfléchir en était conforté, sous-tendant le raisonnement implicite que l'utilisateur réfléchit aussi vite qu'il le peut, indépendamment de son environnement. Les systèmes actuels, abondamment pourvus en MIPS, Gigs et Mbits, peuvent fournir à des milliers d'utilisateurs des temps de réponse inférieurs aux deux secondes "fatidiques", mais les mêmes enjeux persistent... WJ Doherty (IBM) et RP Kelisky (IBM) écrivaient en 1979 : "... chaque seconde perdue à cause du TdRS entraîne une dégradation proportionnelle du temps de réponse de l'utilisateur. Ce phénomène semble lié à une baisse de l'attention de l'individu. Le modèle traditionnel d'une personne réfléchissant après chaque réponse du système semble être invalide. Par contre, les gens semblent agir comme s'ils avaient à l'esprit une séquence d'actions, un buffer mental à court terme. L'augmentation du TdRS semblerait casser les processus de pensée et pourrait obliger à repenser la séquence d'actions restant à accomplir".


Dans un article inspiré des travaux de Doherty, AJ Thadhani (IBM) suggéra que le nombre de transactions par heure, accomplies par un programmeur, augmente sensiblement quand le temps de réponse diminue sous les deux secondes et très fortement dès qu'il passe sous la seconde. Thadhani remarqua (Figure 2) que, soumis à un TdRS de 3 secondes un programmeur effectue 180 transactions à l'heure, alors que pour un TdRS diminué à 0,3 seconde ce nombre passe à 371. Autrement dit, une baisse du TdRS de 2,7 secondes entraîne une économie de 10,3 secondes par transaction (voir la Figure 3).

Figure 2. Nombre de transactions suivant le TdRS



* Figure 24tdr2 not displayed.




Figure 3. Nombre de transactions suivant le TdRS



* Figure 24tdr3 not displayed.


Bénéfices

Les bénéfices potentiels générés par des TdRS améliorés se déclinent en économies substantielles, une meilleure productivité personnelle, un raccourcissement de la durée des projets, et une meilleure qualité de travail.

Economies directes

Economiser quelques secondes d'une personne semble d'un intérêt minime, mais ces secondes peuvent s'accumuler jusqu'à représenter rapidement beaucoup d'argent... assez pour justifier la mise en place d'un système plus performant. Ces bénéfices cachés ont été mis en lumière à l'Institut National de la Santé des USA (NIH). En 1979 (hé, oui), le système du NIH était con\u pour supporter 300 utilisateurs (pour des activités de traitement de texte, programmation, calcul et soumission de travaux à distance), dont 80% des transactions étaient traitées en moins d'une demi-seconde. Dans ces conditions, le système donnait toute satisfaction ; mais l'accroissement de la charge mena\a le maintient de ce niveau de service (Figure 4). Le nombre d'utilisateurs simultanés augmenta à près de 400, et les prédictions étaient de 500 dans les 18 mois suivants... Avec 390 utilisateurs, le TdRS s'était écroulé à 4 secondes et le temps nécessaire pour effectuer une tàche était passé de 32 à 48 minutes (Figure 5). Pour résoudre ce problème, le responsable informatique du NIH proposa une mise à niveau du processeur. Il avait observé que la détérioration de la disponibilité du système entraînait, chaque mois, un surplus de 22 500 heures de présence au terminal des utilisateurs... pour effectuer le même travail, Le surcoût total a été estimé à 900 000 dollars par mois, soit quinze fois le prix d'achat d'un processeur fournissant des TdRS sous la seconde.

Figure 4. Nombre de sessions suivant le TdRS



* Figure 24tdr4 not displayed.


Figure 5. Durée moyenne d'une tàche en fonction du TdRS



* Figure 24tdr5 not displayed.


Productivité individuelle

L'amélioration de la productivité individuelle est sûrement l'aspect le plus sensible affecté par le TdRS. Après la publication de l'étude de Thadhani, de nombreux projets au sein d'IBM tentèrent de confirmer ces travaux en déterminant plus précisément l'impact réel de TdRS inférieurs à la seconde. Un de ces projets concernait la Division des Produits Systèmes. Parmi d'autres produits interactifs, les laboratoires de cette division fournissaient à leurs ingénieurs des assistants graphiques, afin de les aider dans la conception des puces, cartes et autres composants électroniques. Ces ingénieurs utilisaient ainsi des écrans graphiques spécialement étudiés pour les taux de transaction élevés que demande la manipulation d'images.
Les études de cette division portèrent sur 75 sessions de travail de 15 ingénieurs effectuant diverses tàches de conception. L'échantillon de données recueilli confirma l'existence de la courbe de Thadhani. Mais les résultats (Figure 6) mirent plus en évidence, d'une part, que tous les utilisateurs bénéficiaient de l'amélioration de TdRS, d'autre part, qu'un ingénieur, considéré comme moyennement expérimenté, travaillant avec un système répondant en moins d'une seconde, était alors aussi productif qu'un ingénieur expert travaillant avec un TdRS médiocre. De même, un débutant rattrapait un ingénieur "standard", alors que la productivité d'un expert était largement améliorée. La Division des Produits Systèmes mit alors en place une série de tests supplémentaires, pour déterminer l'impact du temps de réponse sur la durée d'une tàche. Pour ces mesures, une tàche de conception de circuit intégré fut confiée à un groupe d'ingénieurs. Il leur fut demandé de l'effectuer dans des conditions pour lesquelles le TdRS était une variable primordiale. Les tests effectués, on fit la corrélation entre la durée totale d'exécution du travail par chaque ingénieur et le TdRS qui lui avait été affecté.

Figure 6. Nombre de transactions suivant le TdRS



* Figure 24tdr7 not displayed.



Tous les résultats, provenant de quatre laboratoires, montraient des différences significatives sur le temps passé à l'achèvement de cette tàche (voir la Figure 7). Dans un laboratoire, la durée de conception diminua de 4,5 minutes pour chaque dixième de seconde gagné sur le temps de réponse. Le temps de dessin d'une carte passa de 92 à 66 minutes ; une amélioration de 20% obtenue en faisant passer le TdRS de 6 à 0,25 secondes. Dans un autre laboratoire, la durée da la tàche fut réduite de 3,6 minutes pour chaque dixième de seconde gagné sur le TdRS, soit un temps de conception passant de 36 à 23,5 minutes. De même, on constata une amélioration de 35% de la productivité en diminuant le TdRS de 0,6 à 0,25 seconde.

Figure 7. Durée totale d'une tàche en fonction du TdRS



* Figure 24tdr8 not displayed.


Impact sur la durée des projets

L'encadrement de l'équipe de développement d'IBM Portsmouth (Angleterre) pris connaissance des potentialités dévoilées par les travaux de Doherty et Thadhani. Dans leurs propres tests, ils fournirent à chaque programmeur un nouveau projet avec des TdRS sous la seconde, puis on mesura la productivité de chaque programmeur et groupe de programmeurs. Des techniques existaient déjà depuis plusieurs années quant à l'estimation de la durée et des ressources nécessaires à l'accomplissement d'un projet. Ainsi, toute déviation vis-à-vis des estimations pouvait être considérée comme une variation significative et validait la comparaison entre groupes de travail. Les estimations reposaient sur une unité appelée "point de fonction", basée sur la taille et la complexité des développements. La plus grande partie des terminaux étaient desservis par un réseau assez lent. Pour le test, les terminaux furent raccordés à un réseau local à haut débit. Ce changement faisait chuter le TdRS de 2,3 à 0,84 secondes. Au vu du nombre de points de fonctions attendus pour le développement, la durée de finalisation du projet avait été estimée à 30,8 mois/homme, répartis sur 19 semaines... En fait, il fut achevé en 15 semaines et ne demanda que 18,7 mois/homme, soit 39 % de moins que prévu, La productivité de l'équipe testée fut aussi comparée avec celle qui avait été mesurée sur un projet similaire, six mois plus tôt. Avec un système répondant en moins d'une seconde, un programmeur écrivait 14,4 points de fonction par mois, soit 58% de plus que les 9,1 points de fonction produits lors du précédent projet.

Amélioration de la qualité

Gràce à une meilleure qualité de service que celle à laquelle ils étaient accoutumés, les programmeurs explorèrent un plus grand nombre de solutions possibles, qu'ils n'auraient normalement pas examinées, et augmentèrent l'étendue de leur travail sur écran. La qualité du programme fut comparée à la lumière des statistiques existantes. Un taux de seulement trois problèmes par centaine de points de fonction fut constaté, à comparer aux 6,9 problèmes par centaine de points de fonction du projet précédent.

Champs d'application

Les études décrites jusqu'ici, dans cet article, concernent des scientifiques, des ingénieurs et des programmeurs. Un test portant sur des tàches administratives indique que les mêmes bénéfices peuvent être attendus, si l'on augmente la réactivité des applications d'accès à des bases de données. Au laboratoire IBM de Poughkeepsie, un groupe de personnes est chargé de prévoir le nombre de pièces à produire, en s'appuyant sur une application exploitant une base de données. Son travail comprend la maintenance de cette base, le référencement des pièces et la saisie des durées de production... soit une série de tàches similaires à celles de tout prévisonnaire de production dans beaucoup d'entreprises. Cinq de ces personnes firent l'object de mesures pendant une demi-journée, durant laquelle elles bénéficièrent d'un TdRS sous la seconde alors qu'il était habituellement supérieur ou égal à 5 secondes. La productivité moyenne, qui était de 99 transactions à l'heure, passa à 336 transactions à l'heure, soit une augmentation de 339%...,

Effet sur les autres travaux informatiques

L'amélioration du TdRS ne diminue pas la demande de puissance informatique ; elle compresse la durée des tàches. Il en ressort que : plus il y a de tàches pouvant être effectuées durant une journée de travail, plus grande est la charge de traitement (interactif et batch) à laquelle l'ordinateur doit pouvoir faire face, si l'on veut éviter de perdre les gains générés par un meilleur TdRS. Un exemple permet d'illustrer cet effet. Considérons que la saisie, la compilation et la mise au point d'un programme nécessitent 100 millions d'instructions. De plus, supposons que ces tàches sont effectuées par un programmeur en une journée de travail divisée successivement en de l'activité sur terminal suivie par des compilations durant deux heures. Pour augmenter la productivité du programmeur, il faut abaisser le TdRS interactif sous la seconde et ramener le temps de compilation à une heure. Le programme pourra alors être écrit en 4 heures, l'exécution du million d'instructions ne prenant plus qu'une demi-journée. Les données récoltées au NIH et au laboratoire de Portsmouth viennent à l'appui cette conclusion. Au NIH, chaque "session de travail" comprenait en moyenne 90 transactions et deux soumissions de batch. Ceci ne fut aucunement modifié par les conditions de l'étude, même si la durée de la session était diminuée en rapport de la baisse du TdRS. A Portsmouth, la "charge processeur" nécessaire pour écrire un point de fonction a été relativement constante, mais la "consommation processeur" des programmeurs favorisés augmenta parce qu'ils produisaient plus de lignes en une journée. Ainsi, pour bénéficier complètement des améliorations de productivité induites par la baisse du TdRS, le système informatique doit être préparé à améliorer tous ses niveaux de service. Ceci peut être accompli :

Coûts et Bénéfices

Pour mettre en évidence les bénéfices d'une chute du TdRS, nous pouvons les illustrer par un exemple basé sur les résultats publiés par Thadhani. L'utilisateur moyen effectue 180 transactions à l'heure quand il est soumis à des temps de réponse de 3 secondes. Pour simplifier, on supposera qu'une tàche nécessite 180 transactions ; huit de ces tàches occupent donc une journée de travail. On suppose, de plus, que l'heure de travail de cet employé revient à 200 Francs (NDLR - Valeur francisée et actualisée par rapport au document original...). En faisant varier le TdRS à partir des données recueillies par Thadani, on arrive au tableau suivant :

Table 16. Gains apportés par la diminution du TdRS.
TdRS
en secondes
Transactions
par heure
Tàches
par minute
Minutes en moins par tàche Minutes en moins par jour
3.0 180 60.0 - -
2.0 208 51.9 8.1 64.8
1.0 252 42.9 17.1 136.8
0.6 279 37.7 22.3 178.4
0.3 371 29.1 30.9 247.2

A mesure que le TdRS s'améliore, le temps nécessaire pour effectuer une tàche passe de 60 à 29,1 minutes ; le temps économisé dans une journée atteint donc 247,2 minutes, ce qui, pour un mois de 21 jours, équivaut à 17 300 Francs. Le nombre d'utilisateurs simultanés sur le système varie d'une entreprise à l'autre, tout comme les potentialités d'améliorations. Toutefois, dans tous les cas de l'exemple étudié ici, l'intérêt financier n'est pas négligeable, allant de 860 KF/mois (10 MF/an) pour un système desservant 50 personnes à 5,2 MF/mois (62 MF/an) pour 300 utilisateurs simultanés.

Conclusion

Des temps de réponse rapides, idéalement inférieurs à la seconde et dans un environnement informatique adéquat, offrent des améliorations significatives de la productivité de ceux qui en bénéficient. IBM et d'autres entreprises ont pu le vérifier et ont démontré que cela diminuait le coût des tàches effectuées sur informatique. Bien sûr, chaque organisation peut mettre en place ses propres procédures de mesure, mais, comme cet article l'a illustré, les enjeux peuvent être importants.


Cet article montre bien que la productivité n'est pas uniquement liée à l'interface utilisateur. De nos jours, les projets de revamping peuvent oublier l'aspect primordial d'une application qui est son temps de réponse. Temps de réponse qui dépend, non seulement du système d'hébergement et du réseau de communications, mais aussi de l'architecture applicative ainsi que de l'ergonomie de l'interface utilisateur (ce qui prenait 2 écrans en application classique se transforme en 10 écrans en HTML, ). La finalité d'une application n'est pas seulement d'ordre esthétique. Elle s'inscrit généralement dans un contexte économique.      .


Footnotes:

(3) Cette assertion de 1982 n'est sans doute plus valable aujourd'hui... quoique,


[ Top of Page | Previous Page | Next Page | Table of Contents ]