Vidéo: Module 134 - Finance anglo-saxonne : Outils et ratios d'analyse de la rentabilité 2025
L'analyse des performances est probablement l'une des tâches les plus complexes dans la conception d'une application. C'est une science imprécise parce qu'il y a beaucoup de facteurs qui entrent en jeu. Ceux-ci sont augmentés dans les applications Enterprise JavaBeans (EJB), où les performances dépendent en grande partie de l'implémentation du conteneur EJB que vous utilisez. L'essentiel est que vous ne pouvez pas savoir si vous prenez les bonnes décisions de performance avant de les tester.
Vous devez garder à l'esprit les problèmes suivants lors de l'examen des problèmes de performances:
- Tous les conteneurs EJB ne sont pas créés égaux. Bien que chaque conteneur EJB doit être conforme à la spécification EJB, les fournisseurs disposent d'une grande latitude pour implémenter le conteneur EJB. Leurs exigences se concentrent sur les résultats des opérations, et non sur l'efficacité d'une opération. Certains fournisseurs feront un meilleur travail avec différentes parties d'un conteneur EJB. Vous devez déterminer où des gains d'efficacité peuvent être obtenus dans un conteneur EJB et où des goulets d'étranglement de performance vont se produire. La seule façon de le savoir avec certitude est d'essayer avant d'acheter. Même après l'achat d'une solution, les principales décisions de conception, telles que l'utilisation ou non des beans entité EJB, doivent être testées.
- Les performances peuvent dépendre de l'efficacité de votre application. Il existe des règles générales que vous pouvez utiliser pour déterminer quelles conceptions d'application sont meilleures que d'autres. Mais ces directives peuvent être facilement invalidées avec une implémentation bâclée. La meilleure façon de vous éviter les implémentations bâclées est d'effectuer régulièrement des révisions de code , c'est-à-dire lorsque vous vous asseyez avec tous vos collègues codeurs et demandez-leur de revoir votre travail - pendant votre projet EJB. Vous devriez concentrer vos revues de code sur l'analyse de la source et s'assurer qu'elle est à la fois bien conçue et efficace. Les critiques de code offrent une excellente opportunité pour les programmeurs d'apprendre les uns des autres.
- Développez un prototype pour tester vos hypothèses de performance. Voici un exemple de scénario. En tant que développeur d'applications EJB, vous devez décider très tôt d'utiliser ou non les beans entité pour gérer l'interaction avec une base de données. Vos deux choix de base sont
• Créer des beans entité pour gérer l'interaction de la base de données. Les beans entité peuvent simplifier l'interaction de votre base de données à partir d'une perspective de programmation d'application. Mais ils peuvent également exiger une pénalité de performance. Une partie de cette pénalité peut être contrôlée de la même manière que vous implémentez des beans entité, c'est-à-dire en utilisant des interfaces locales par rapport à des interfaces distantes ou en faisant des beans entité des objets grossiers.
• Le code de la base de données JDBC appelle directement les beans de session et évite l'utilisation des beans entité. JDBC peut être plus difficile à utiliser que d'utiliser des beans entité avec une persistance gérée par le conteneur. Ce cours peut également nuire à votre capacité à tirer parti des transactions gérées par conteneur EJB.
Pour déterminer lequel des deux cours est le plus approprié, vous pouvez effectuer un test simple:
1. Créez un bean entité et un bean session qui effectuent tous deux des opérations sur le même ensemble de données à partir d'une base de données.
2. Ecrivez un programme simple qui mesure la durée nécessaire pour appeler un ensemble d'insertions, de mises à jour, de requêtes et de modifications dans la base de données.
Ce deuxième programme devrait appeler le bean session pour un test et le bean entité pour un autre test - effectuant le même ensemble d'opérations sur chacun.
3. Analyser les résultats pour déterminer si les performances seront un problème.
Si vous souhaitez une analyse des performances plus fine, vous pouvez planifier des étapes individuelles (pour identifier l'opération la plus coûteuse), puis essayer de modifier ces opérations pour générer des gains de performances.
Pour un bean entité, vous pouvez mesurer les performances sur les opérations suivantes:
- Combien de temps faut-il pour obtenir une référence à une interface distante ou à une interface locale?
- Quelle est la différence de performance entre l'exécution d'une mise à jour sur une interface distante et une interface locale?
- Quelle est la différence entre la mise à jour de plusieurs lignes dans une base de données dans JDBC et l'exécution d'une mise à jour sur plusieurs lignes à l'aide de la méthode home d'un bean entité?
Les réponses à ces questions seront différentes de celles du conteneur EJB et du conteneur EJB. Elles seront également influencées par: a) le pilote JDBC que vous avez choisi; b) si vous utilisez ou non le regroupement de connexions à la base de données; et c) l'efficacité de vos implémentations du bean entité et du bean session. Vous serez probablement surpris par certains des résultats que vous obtenez - des tests comme ceux-ci ont un moyen de remettre en question vos hypothèses sur la performance des beans entité.
Lorsque vous réglez un EJB pour des performances, ne faites pas de modifications aléatoires. Au lieu de cela, concentrez votre attention sur les étapes de l'application qui coûtent le plus en termes de performances.
Remarque: Les mesures de performances révèlent généralement qu'un processus métier n'a qu'un ou deux points où des améliorations significatives peuvent être apportées. Cette observation a été faite assez souvent que cela a conduit à la création de la règle Pareto 80-20. Cette règle stipule que 80% du temps d'exécution d'un programme est dû à 20% du code. Votre objectif devrait être d'identifier les 20% du code les plus chers en termes de ressources système et de vous concentrer sur l'optimisation de cette partie.
