Ce niveau utilise un ensemble d'outils et de techniques pour diagnostiquer ponctuellement des applications qui semblent avoir des problèmes de performances ou qui sont candidates à l'optimisation. Vous pouvez utiliser ces outils et techniques pendant le développement et le déploiement initial, et aussi quand un problème ou une application à
Niveau 3 – Diagnostic des performances d’applications

forte utilisation a été identifié
par la supervision du niveau 2. Les figures 11, 12 et 13 contiennent
quelques-unes des questions auxquelles
il est répondu pendant l’activité
du niveau 3, les mesures à collecter
et les rapports types.
D’autres outils permettent une collecte
de données supplémentaires :
Database Monitor, Performance Explorer
(PEX) de Performance Tools/ 400
(PT/400), et routines de journalisation
des temps de transaction écrites localement.
Les outils potentiels pour
produire des rapports sont les suivants
:PT/400, rapports iSeries Navigator
SQL Monitor, Visual Explain,
iDoctor PEX Analyzer, PTDV, outils
tierce partie et requêtes personnalisées.
Lorsque vous planifiez les outils de
diagnostic à utiliser, songez à plusieurs stratégies utiles. Les deux règles les
plus importantes sont les suivantes :
- L’intuition est mauvaise conseillère
pour trouver la cause des problèmes
de performances ou leur solution.
Utilisez toujours quelques mesures
techniques pour confirmer les
causes d’un problème et pour vérifier
que votre solution fonctionne (et
qu’elle n’entraîne pas d’autres problèmes). - Avant de corriger un problème de
performance, assurez-vous qu’il en
vaut la peine. Là encore, utilisez une
technique de mesure quantitative
pour sélectionner vos efforts d’optimisation
et pour déterminer leur
priorité.
Il est bon également d’ajouter du
code « d’instrumentation » à vos applications
afin de pouvoir capturer les
données d’utilisation et de performance
liées à des fonctions d’application
spécifiques. Par exemple, dans le
cas d’une application de traitement
transactionnel interactive, vous pouvez
ajouter du code chargé de générer des
entrées de journalisation de performances
(comme écrire des enregistrements
dans un fichier) qui capturent
des informations telles que les types de
transactions, les données saisies, les résultats,
et le temps écoulé. Ce type de
code d’instrumentation doit être
conçu de telle sorte que l’on puisse
l’activer et le désactiver selon les besoins,
sans être obligé de recréer des
objets programme. La journalisation
dynamique des performances propres
aux applications est un moyen précieux
pour suivre efficacement les
sources des problèmes de performances.
Pour certaines fonctions applicatives,
le benchmarking est un bon
moyen de mesure de performance relative.
Le benchmarking convient particulièrement
dans le cas de fonctions
non interactives à calculs intensifs.
Ainsi, si vos applications appellent une
routine pour une application financière complexe, vous pouvez écrire un
driver qui appelle de façon répétitive
cette routine avec une plage de valeurs.
Vous pouvez utiliser un tel
benchmark de plusieurs manières.
L’exécution d’un benchmark permet
d’estimer approximativement le
temps et les ressources qu’utilise une
fonction particulière. Ainsi, si une routine
chargée d’une opération financière
complexe dure en moyenne un
quart de milliseconde par appel, et si la
routine est appelée deux millions de
fois au maximum dans votre job batch
le plus long, l’optimisation peut procurer
un gain potentiel d’environ huit minutes.
Ce genre d’évaluation permet
de décider si cette routine est digne,
ou non, du travail d’optimisation.
Pendant un benchmark, vous pouvez
aussi utiliser des outils de performance
comme PEX, pour mesurer
quelles ressources sont en service et
quelles parties du code contribuent le
plus au temps d’exécution. L’exécution
de benchmarks avant et après est aussi
un moyen de juger des résultats du travail
d’optimisation, du réglage du système
ou d’un nouveau matériel.
Il est plus difficile d’appliquer des
benchmarks fiables à des applications
interactives ou Web. Attention aussi
aux benchmarks autonomes de routines
lourdes en I/O base de données :
on risque des résultats trompeurs, dus
au caching par exemple.
Téléchargez cette ressource

Percer le brouillard des rançongiciels
Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
