Commentaires sur : Performance, les Xebians jouent les démineurs

Par : JPL

JPL — Mon, 26 Apr 2010 07:59:03 +0000

@Pablo
Soit… Mais j’aurais préféré une conclusion s’attachant à démontrer qu’il s’agit d’actions préalables (une mise en bouche en quelque sorte) plutôt qu’une conclusion trop axée, à mon goût, sur le bénéfice en terme de performance des premières optimisations.
Sans polémique, la démontration reposant sur les problèmes de circulation de l’A10 (que je connais très bien puisque je vis sur la région bordelaise)/péage de St Arnoult/Cuvette des Ulis lorsqu’il n’y a qu’un seul automobiliste sur la route n’est pas très convainquante. (:-))

Par : Pablo Lopez

Pablo Lopez — Wed, 14 Apr 2010 07:48:17 +0000

@JPL
Merci pour votre commentaire.
En effet, le temps global de transaction n’est qu’un moyen de mesure parmi d’autres et comme annoncé en préambule, cette démonstration est plus scolaire que « dans les conditions du réel ». Cependant, il n’est pas choquant de voir le temps global s’améliorer alors que le temps d’exécution de certaines transactions se dégrade. La levée d’un point de contention peut reporter et / ou mettre en évidence un problème plus loin dans l’enchainement des actions (cf, pour les parisiens, l’A10, avec l’enchainement péage de Saint Arnoult – Cuvette des Ulis .

Quoi qu’il en soit, votre remarque est pertinente, pour être exhaustif, il aurait fallu déterminer les scenarii critiques (ceux dont on veut absolument valider la bonne santé), surveiller le comportement aux limites (en particulier en terme de nombres d’utilisateurs), la sollicitation des ressources machines (mémoire, CPU, comportement en environnement distribué)… Encore une fois, il s’agit d’aborder les performances sous le jour d’un exercice didactique, et de donner des pistes et des outils à tous ceux qui ne se sont jamais frotté à ce type de diagnostic.

Par : JPL

JPL — Fri, 26 Mar 2010 18:47:19 +0000

Bonjour,
A première vue la démonstration est séduisante, mais lorsqu’on regarde de plus prêt les informations transmises par JMeter, elle devient tout d’un coup beaucoup moins convainquante. En effet, l’essentiel de la démonstration consiste à analyser les améliorations en comparant le temps de réponse moyen du scénario. Ors on peut se demander si c’est vraiment une bonne approche lorsqu’on regarde par exemple les TR moyens de la transaction « Owner details », ils se sont malheureusement dégradés sur le dernier tir (celui bénéficiant de toutes les optimisations décrites dans cette page). Par contre si l’on prend le TR moyen de la transaction « vets », il passe respectivement de 2928 ms à 2818 (jusque là tout va bien ) ) puis 672 (merveilleux!).
En fait les TR de réponses ne semblent pas vraiment stables et je ne pense pas que l’on puisse conclure que ces 2 optimisations ont, à elles seules, permis de diminuer les temps de réponse d’une façon aussi spectaculaire… Ou alors il faudrait m’expliquer également la raison pour laquelle avec les mêmes optimisations, les TR moyens de certaines transactions augmentent.
Je ne conteste pas l’action visant notamment à diminuer la sollicitation du mécanisme de trace qui peut s’avérer contre productive (surtout lorsqu’on s’interesse à l’exploitabilité de la solution).
J’attends avec impatience le reste de la démonstration!

Par : jay

jay — Wed, 03 Feb 2010 17:55:46 +0000

Très bon exercice, qu’il serait intéressant de reprendre… L’appli source est dispo qqpart?

Par : Romain S

Romain S — Fri, 29 Jan 2010 19:53:02 +0000

@Pronostic: A croire que tu étais présent au XKE ^^

Par : pronostic

pronostic — Fri, 29 Jan 2010 14:16:12 +0000

Alors mon petit pronostic pour la suite:
- gzip
- peut etre des synchronized qui font goulet d’etranglement
- pour améliorer les perts multi trheader des tâches
- showSql à false
- lazy à true
- des requêtes HQL trop complexes
- augmenter le pool de connexion SQL
- du @transaction en trop
- un petit cache peut etre

Je suis curieux de savoir ce que vous allez mettre en place pour la suite