Cet article est la traduction d’un article de Doug Burns publié sur son blog. L’article original en anglais se trouve ici.

C’est une réflexion sur la principale métrique de performance: le temps de réponse, ou le débit (nombre de transaction par unité de temps) en fonction de ce qui est étudié: requête d’une session individuelle, ou charge globale d’un système (workload).

J’ai été incité à écrire cet article a la suite du commentaire suivant que Niall Litchfield a fait dans un email:
« … Je remarque qu’une fois qu’on commence à définir une charge globale de travail (workload), ou un ensemble de transactions, dans des termes métier (du genre ‘j’ai besoin d’effectuer toutes ces choses, qu’est-ce qui marche le mieux ?’) alors le temps de réponse de la charge de travail complète ^* a un sens, d’une part comme métrique, mais surtout comme un objectif de tuning. J’ai l’impression que depuis ces 10 dernières années, les discussions sur les performances se font autour des requêtes, ou de l’optimisation d’une session, en supposant que si on améliore les performances d’une requête particulière, alors on va aussi améliorer la charge de travail complète, telle que le voit le métier. C’est souvent vrai, mais c’est souvent faux aussi. Les mesures de performances seront toujours basées sur le temps de réponse, mais il pourrait y avoir des d’autres méthodes de tuning. Ça pourrait être aussi simple que de définir la première étape du tuning comme ‘Définir la charge de travail (workload) la plus importante important pour le métier’ au lieu de ‘définir la tâche importante pour le métier’

Je suis d’accord avec Niall, particulièrement sur le fait actuellement on met plus l’accent sur l’optimisation de sessions individuelles, ou des requêtes isolées, plutôt que l’optimisation de la charge de travail globale.

Je vais dire cela d’une autre manière: si vous essayez d’avoir le meilleur débit pour toute la charge de travail (workload throughput) alors l’objectif le plus important n’est peut être pas le meilleur temps de réponse d’une session individuelle.C’est pourquoi j’ai quelques slides d’un cours que j’ai écris auparavant pour Oracle et qui définissent plusieurs façons d’évaluer les performances du système, incluant:

• le temps de réponse (response time)
• le débit (throughput)
• et l’évolutivité (scalability)

Je vais essayer d’illustrer ces deux objectifs différents à l’aide de l’utilitaire Swingbench de Dominic Giles. J’ai exécuté le benchmark système de commandes (SOE) en variant le nombre d’utilisateurs simultanés sur une période de 3 minutes. L’instance Oracle, la configuration matérielle (ordinateur portable dual-core avec le disque dur habituel pas très rapide) et le code de l’application sont identiques pour tous les tests.

La seule variable significative est le nombre de sessions concurrentes. Voici les résultats (tel que Swingbench l’affiche dans l’onglet Sortie).

Sans aucun doute, on a le meilleur temps de réponse avec un seul utilisateur qui exécute le test, et ce temps de réponse augmente au fur et à mesure que le nombre de sessions actives s’accroît. Mais par contre, avec seule session le nombre de transactions effectuées pendant le test est le plus faible. Si nous voulons traiter autant d’opérations que possible dans les 3 minutes, alors il semble que nous devrions avoir environ 28 sessions en parallèle.

Mais est-ce qu’on doit s’inquiéter du fait que la durée moyenne des transactions a atteint 587 millisecondes? Eh bien, si les transactions ont une interaction avec des utilisateurs, alors oui, le temps de réponse est important. Je suis sûr que vos utilisateurs attendent la réponse la plus rapide possible. Et si nous mettons 28 sessions actives, alors chaque utilisateur va avoir des performances 5 fois plus lentes que si il était seul. Oh, et ce n’est que le temps de réponse moyen – le pic serait bien pire !

Si, par contre, ces transactions font partie d’un batch de nuit dont l’objectif est d’effectuer une charge de travail complète dans la durée la plus courte possible, alors notre priorité sera le nombre de transactions effectuées, et qui se soucie du fait que chaque opération individuelle prend un peu plus de temps ? C’est un cas où il est préférable de charger le système à fond quitte à augmenter le temps de réponse individuel des transactions. Ça paraît paradoxal de planifier la charge du système d’une manière qui augmente le temps de réponse. Par exemple, si je prends une sessions au hasard au cours de chacun des tests, que je la trace analyse cette trace, est-ce que ce n’est pas le premier scénario qui apparaîtra comme plus performant ? Mais c’est parce que que je me serai focalisé que sur une seule session.

Alors, est-ce que c’est le premier test ou le dernier qui est le plus performant ? Et bien, tout dépends de ce que vous entendez par performant.

Maintenant, voici où je voulais en arriver: c’est une erreur tracer et faire le tuning d’une session individuelle. En fait, tous ces essais auraient donné des résultats encore plus impressionnants si j’avais amélioré les performances de l’application SOE au niveau session d’abord, pour que chaque transaction utilise moins de ressources et se termine plus rapidement. C’est une bonne chose. Je comprends que l’analyse et le tuning au niveau d’une session est essentielle. Mais, si chaque session a déjà a été optimisée, alors il y a d’autres aspects que nous avons besoin d’étudier, et la trace d’une session individuelle ne me donne pas les informations dont j’ai besoin. (Oh, je ferais mieux d’être prudent parce que je ne suis pas loin de suggérer que STATSPACK et AWR peuvent être des outils utiles pour certaines situations, après tout !)

Cependant, quand on observe une telle amélioration du débit, sur mon ordinateur portable, lorsque j’ai augmenté la charge sur un test simple, il faut être très prudent:

1. Bien que le batch a effectué plus de travail dans la même période de temps, grâce à l’augmentation du parallélisme, il a également ralenti le temps de réponse de tout le reste. C’est pourquoi il n’est pas judicieux de mélanger les batch avec des sessions interactives.
2. Lorsque le nombre de session augmente au delà d’un certain point, le travail effectué diminue. Le système commence à souffrir de contentions et nous nous éloignons de notre but, tout en utilisant encore plus de ressources. Il faut trouver le bon équilibre.
3. En regardant les résultats une fois de plus, est-ce qu’on a vraiment le meilleur équilibre avec 28 sessions en parallèle, alors que avec 16 sessions le débit est presque le même ? Eh bien, je prendrais toujours 16 sessions pour ce job dans la même configuration, si ça réponds aux exigences. Pousser la performance d’un système toujours à la limite peut conduire un jour à un problème de performances grave, parce que cela réduit la marge de manÅ“uvre qui peut aider à faire face à des événements imprévus.

Tout ce que je cherche à dire ici, c’est que l’analyse des performances, l’optimisation du temps de réponse, la gestion de la charge de travail (appelez ça comme vous voulez) ne peut et ne doit pas se limiter à examiner la performance d’une seule session isolée.

* C’est juste moi, ou bien le terme de ‘temps de réponse’ est un peu bizarre lorsqu’il est appliqué à une charge de travail globale (un workload). C’est la même idée que le temps de réponse d’une session (combien de temps il faut pour aller du point de départ à la fin) mais il me semble que c’est quelque chose de différent. C’est peut-être mon manque de compréhension, de lecture ou de rigueur, mais je trouve étrange de parler d’un temps de réponse global, agrégé, pour un système, un workload, ou un ensemble de plusieurs utilisateurs. Je comprends ce que veut dire: commencer / faire beaucoup de travail / terminer. Mais est-ce que le temps que cela prend est vraiment un temps de réponse, ou plutôt un débit (throughput) ? Est-ce que j’ai trop l’habitude d’associer le temps de réponse avec un utilisateur qui assis devant son écran, à attendre une réponse ?