Analyse des performances dans les Enterprise JavaBeans

Analyse de la performance est probablement l'une des tâches les plus complexes dans la conception de toute application. Il est une science imprécise, car il ya beaucoup de facteurs qui entrent en jeu. Ceux-ci sont complétés dans EJB (Enterprise JavaBeans), des applications où la performance dépend en grande partie sur la mise en œuvre du conteneur EJB vous utilisez. La ligne de fond est que vous ne pouvez pas savoir si vous faites les décisions de performance de droite jusqu'à ce que vous les tester.

Voici quelques questions que vous devriez garder à l'esprit lorsque l'on considère les problèmes de performance:

• Pas tous les conteneurs EJB sont créés égaux. Bien que chaque conteneur EJB doit être conforme à la spécification EJB, les vendeurs ont une grande latitude dans l'application du conteneur EJB. Leurs besoins se concentrent sur les résultats des opérations, pas sur l'efficacité d'une opération. Certains fournisseurs vont faire un meilleur travail avec les différentes parties d'un conteneur EJB. Vous devez déterminer où des économies peuvent être acquises dans un conteneur EJB et où vont les goulets d'étranglement de performance de se produire. La seule façon de savoir avec certitude est d'essayer avant d'acheter. Même après que vous achetez une solution, les grandes décisions de conception, comme si oui ou non d'utiliser des beans entité EJB, devraient être testés.

• La performance peut dépendre de l'efficacité de votre application. Il existe des règles générales que vous pouvez utiliser pour aider à déterminer quelle application conceptions sont mieux que d'autres. Mais ces lignes directrices peuvent être facilement invalidés avec une mise en œuvre bâclée. La meilleure façon, vous éviterez ainsi les implémentations bâclée est d'effectuer régulièrement revues de code - qui est quand vous asseoir autour de codage avec tous vos collègues et de les faire examiner votre travail - au cours de votre projet EJB. Vous devez vous concentrer vos revues de code sur l'analyse de la source et de veiller à ce qu'elle est à la fois bien conçu et efficace. Les examens du code offrent une excellente occasion pour les programmeurs d'apprendre les uns des autres.

• Développer un prototype pour tester vos hypothèses de rendement. Voici un exemple de scénario. En tant que développeur d'applications EJB, vous devez décider dès le début ou non d'utiliser des beans entité pour gérer l'interaction avec une base de données. Vos deux choix fondamentaux sont à

# 8226- Créer des beans entité pour gérer l'interaction de base de données. Les beans entité peuvent simplifier votre interaction dans une perspective de programmation d'application de base de données. Mais ils peuvent aussi exiger une pénalité de performance. Une partie de cette peine peut être contrôlé dans la façon dont vous implémentez des beans entité - qui est, en utilisant les interfaces locales par rapport aux interfaces distantes ou en faisant des beans entité objets grossiers.

# 8226- Base de données JDBC appelle code directement dans les beans session et d'éviter complètement l'utilisation de beans entités. JDBC peut être plus difficile à travailler que l'aide de beans entité avec la persistance gérée par conteneur. Ce cours peut également compromettre votre capacité à tirer profit des transactions gérées par le conteneur EJB.

Pour déterminer lequel des deux cours est plus approprié, vous pouvez effectuer un test simple:

1. Créez un bean entité et un bean session que les deux effectuer des opérations sur le même ensemble de données à partir d'une base de données.

2. Écrire un programme simple qui mesure la quantité de temps nécessaire pour invoquer un jeu d'inserts, mises à jour, les requêtes et les changements à la base de données.

Ce deuxième programme devrait invoquer la fève de session pour un test et le bean entité pour un autre test - effectuant le même ensemble d'opérations sur chaque.

3. Analyser les résultats pour déterminer si la performance sera un problème.

Si vous voulez une analyse plus fine des performances, vous pouvez chronométrer les étapes individuelles - pour identifier l'opération la plus chère - et puis essayez de modifier ces opérations de générer des gains de performance.

Pour un bean entité, vous pouvez mesurer la performance 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 effectuer une mise à jour sur une interface distante et une interface locale?

• Quelle est la différence entre mise à jour de plusieurs lignes dans une base de données JDBC et d'effectuer une mise à jour sur plusieurs lignes en utilisant la méthode de la maison d'un bean entité?

Les réponses à ces questions seront différentes de conteneur EJB au conteneur EJB et sera également influencée par: a) le pilote JDBC vous choisir- b) si oui ou non vous utilisez pooling- de connexion de base de données et c) l'efficacité de vos implémentations de la bean entité et le bean session. Vous serez probablement surpris par certains des résultats que vous obtenez - tests comme ceux-ci ont une façon de défier vos hypothèses sur les performances des beans entité.

Lorsque vous accordez une EJB pour la performance, ne pas faire des changements aléatoires. Au lieu de cela, concentrer votre attention sur les étapes de l'application qui a coûté le plus en termes de performances.

Note:Les mesures de performance révèlent généralement que d'un processus d'affaires a seulement un ou deux points où des améliorations significatives peuvent être faites. Cette observation a été faite assez souvent qu'il a mené à la création de la Pareto 80-20 règle. Cette règle stipule que 80 pour cent du temps d'exécution d'un programme est due à 20 pour cent du code. Votre objectif doit être d'identifier les 20 pour cent du code est le plus cher en termes de ressources système et concentrer sur l'optimisation de la partie.