Catégorie: Performance (tuning)

Il n'a a pas eu beaucoup d'articles traduits ces derniers mois. Pour patienter, voici un lien sur une présentation:
Interpreting AWR Report - Straight to the Goal en anglais, mais très visuel...

C'est parfois difficile d'aborder un rapport AWR ou Statspack qui comprends 50 pages de statistiques, dont seulement quelques unes sont utiles dans un contexte donné. J'ai vu plusieurs personnes qui ne savent pas vraiment par où commencer. Et sans une approche méthodique, c'est facile de perdre du temps sur des choses qui ne feront pas gagner un un temps significatif dans l'amélioration du temps de réponse.

Cette présentation montre une approche méthodique: en partant du temps passé en base de données (DB time) pour voir si le rapport est pertinent ou pas, puis en prenant les éléments du 'Top 5 events' en montrant où aller chercher les détails qui permettent de comprendre la raison d'un problème de performance, comment le résoudre, et estimer le gain en temps de réponse que peut apporter la résolution.

Cet article est la traduction d'un article de Cary Millsap publié sur son blog. L'article original en anglais est:Throughput versus Response Time. C'est un commentaire sur l'article de Doug Burns Time Matters: Throughput vs. Response Time. Cary Millsap est un spécialiste de la performance, du tuning Oracle et a beaucoup écrit sur les files d'attentes.

J'ai apprécié le post de Doug Burns Performance: Mesurer le temps de réponse ou le débit sur son blog. Si vous ne l'avez pas encore lu, vous devriez. L'article et les commentaires sont excellents.
La courbe de rendement (temps de réponse en fonction de la charge du système) fait un coude, au point où le temps de réponse, presque constant, devient tout d'un coup exponentiel lorsque le système atteint une certaine charge.

Exemple de courbe de rendement tiré de Optimizing Oracle performance
- En abscisse (ρ): la charge (ou utilisation),
- En ordonnée (R): le temps de réponse.
- Les 3 courbes correspondent à un degré de parallélisme de 1,2 et 8

Le 'coude' ('knee'), est le point correspondant à la charge pour laquelle le rapport temps de réponse / utilisation est minimal.
Il peut être déterminé aussi par la tangente à la courbe, passant par le point d'origine des axes.
Ce 'coude' se décale vers la droite lorsque le degré de parallélisme augmente.

» Lire la suite!

Cet article est la traduction d'un article de Jonathan Lewis publié sur son blog. L'article original en anglais se trouve ici.

J'ai traduit récemment un article de Doug Burns sur un concept très important lorsqu'on étudie les performances d'un système: améliorer le temps de réponse d'un traitement individuel, et améliorer le débit (throughput) d'un ensemble de traitement sont 2 objectifs différents, et souvent contradictoires.

Doug Burns donnait un exemple concret en différenciant la mesure du temps de réponse d'une session individuelle (response time) et la mesure du débit d'une charge globale (throughput). Jonathan Lewis montre ici de manière simple la théorie qu'il y a derrière. Pour aller plus loin dans la théorie, je traduirais prochainement les commentaires de Cary Millsap là dessus.

Je n'ai pas l'intention de rentrer dans la technique des files d'attentes (Queuing Theory) qui est plutôt le domaine de Cary Millsap, mais je voudrais juste donner un exemple pour montrer de quelle manière la théorie des files d'attentes (Queues) s'applique à Oracle, en répondant à la question suivante que m'a posé un client récemment:

"Comment peuvent-ils se plaindre que le temps de réponse a empiré, alors que le débit (throughput) global a augmenté de 5% ?"

La réponse malheureusement est: oui, bien sûr, le temps de réponse est peut-être pire et ceci vient justement du fait que le débit est meilleur, et je vais donner un exemple dans cette note, construit pour montrer comment cela peut se produire.

» Lire la suite!

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)

» Lire la suite!