RENDRE VOS APPLICATIONS JAVA PLUS EFFICACES Ce qu'il faut savoir

Transcription

1 WHITE PAPER RENDRE VOS APPLICATIONS JAVA PLUS EFFICACES Ce qu'il faut savoir JAVA APPLICATION MANAGEMENT ET APPLICATION J2EE.

2 Table des matières INTRODUCTION...2 NAVIGATEURS...2 SERVEURS WEB...3 JVM...3 SERVLETS...4 ENTERPRISE JAVA BEANS...4 JAVA MESSAGE SERVICE...5 J2EE MANAGEMENT INTERFACE...5 RESUME ET CONCLUSIONS...6 POUR VOUS AIDER A GARDER L'AVANTAGE...6

3 Introduction INTRODUCTION Pour les entreprises confrontées au défi consistant à intégrer les applications provenant d'entreprises acquises, la mise en interface des applications sur le Web ou l'accès à une base de données héritée, l application J2EE constitue une solution puissante utilisant une approche fondée sur la programmation standard des applications. Mais comment faire le tri parmi toutes les normes pour trouver les éléments pertinents? Il est facile de conceptualiser l application J2EE si vous la considérez comme un programme Java à l'échelle d'une grande entreprise, cette dernière constituant une plate-forme variée qui sert les processus métier de l'entreprise. Java peut être le dénominateur commun de l'environnement. Il s'agit du langage que vous pouvez utiliser pour construire des éléments individuels qui pourront être reliés pour former une application. La supposition fondamentale de Java tient au fait que si toutes les plates-formes parlent le même langage, les entreprises pourront réduire les coûts liés aux connexions câblées via des moyens propriétaires entre différentes applications installées sur des platesformes différentes. Cette norme permet la création d'unités logicielles, ou objets, indépendants, fonctionnels et réutilisables sur des plates-formes disparates au sein de l'entreprise. Concrètement, cela signifie qu'une entreprise peut développer plus rapidement des applications comprenant des pages Web présentées à l'utilisateur dans un navigateur et une couche d'application, ou principale, plus élaborée. La couche d'application J2EE peut aisément accéder aux données qui résident sur n'importe quelle base de données et interagir avec de nombreux types de services de messagerie intermédiaires. Les plates-formes matérielles des serveurs spécifiques utilisés pour se faire sont la plupart du temps sans conséquence pour l'application. Résultat : l application J2EE constitue la solution idéale pour relever le défi de la connexion et de l'intégration d'applications disparates. délicatement élaborés et intégrés, qui fonctionnent ensemble pour faire tourner les roues. Le développement réussi des applications J2EE est assez similaire. Extérieurement, Java facilite l'intégration et permet de fournir rapidement le service demandé. Alors que le J2EE donne l'impression que la tâche est plus facile, sous son capot se cache une multitude de pièces mobiles qui requièrent une coordination et des performances optimales. En étant attentifs au fonctionnement parfait de ces pièces, les administrateurs et les opérateurs sont à même de proposer un environnement de production plus prévisible et plus fiable. NAVIGATEURS Aujourd'hui, la plupart des utilisateurs accèdent à Internet via un navigateur sur un réseau. Le problème tient au fait que la plupart des programmateurs Java supposent que les pages de navigateur générées par leurs programmes disposeront d'une bande passante illimitée sur le réseau. Malheureusement, ce n'est pas le cas de tous les réseaux (posez simplement la question au propriétaire d'un assistant numérique personnel qui tente de se connecter à Internet depuis un aéroport). Résultat : le navigateur dispose d'un "temps de réponse" médiocre sur son navigateur. La question est alors de savoir qui définit le temps de réponse "médiocre". La définition de médiocre est-elle celle de l'utilisateur du navigateur ou celle du programmateur Java? Les équipes chargées de résoudre les problèmes d'application et de fonctionnement se trouvent dans l'obligation de quantifier la qualité médiocre ou "satisfaisante" du temps de réponse du navigateur. Une fois quantifié, comment collecter le temps de réponse des navigateurs? Pour réussir avec l application J2EE, il est important de comprendre les différentes étapes et composants d'une application Web typique. Certains analystes de l'industrie ont comparé l'évolution des applications informatiques à celle de l'automobile. Les automobiles actuelles constituent un assemblage complexe de composants 2

4 SERVEURS WEB SERVEURS WEB Une fois le temps de réponse du navigateur quantifié, collecté et mesuré, vous devez examiner vos serveurs HTTP (souvent appelés serveurs Web). Ces serveurs décident de la procédure à suivre pour effectuer votre transaction. Si votre transaction est une simple requête de fichier plat (par exemple, une page HTML statique), le serveur Web lui-même récupère généralement la page et la retourne au navigateur. En revanche, si votre transaction comprend un contenu dynamique (par exemple, le solde actuel de votre compte en banque), le serveur peut transmettre votre requête au serveur d'applications Web. C'est là que résident les composants J2EE, notamment les «servlets», les «Java server pages» (JSP) et les «enterprise Java beans» (EJB). Toutefois, avant que la transaction ne soit transmise au monde J2EE, voyons ce que doit encore faire le serveur Web. Les pages de serveur Web communiquées à un navigateur se composent de nombreux éléments différents : pages de texte, images et applications client (telles que les applets Java). En supposant que le temps de réponse à l'utilisateur final se prolonge, comment savoir quelles parties des pages provoquent ce retard global au niveau de la réponse? Le fait de savoir quelle partie des pages du navigateur rencontre un problème pourrait vous aider à accélérer sa résolution. En supposant que tout se passe bien au niveau du serveur Web, votre transaction J2EE est transmise à un servlet qui s'exécute sur la machine JVM. JVM Les servlets coordonnent la logique globale du programme à l'intérieur d'une «Java Virtual Machine» J2EE. Avant d'examiner plus en détails les servlets, attardons-nous sur la machine JVM elle-même. Si la machine JVM fonctionne mal ou n'est pas correctement paramétrée, il est évident que les servlets qui s'exécutent sur cette machine ne seront pas performants. La programmation Java est différente de bien d'autres langages de programmation. Dans les autres langages, votre code est compilé dans le langage de la machine, alors que dans le cas de Java, votre code est également compilé, mais pas dans le langage de la machine. Le code Java est compilé dans un langage que la machine JVM exécutera. Le code Java compilé ne s'exécute pas en natif sur le système d'exploitation, mais sur la machine JVM. Cette dernière doit pour cela allouer de la mémoire (appelée "tas" ou "heap" en anglais) à partir du système d'exploitation, et ce pour deux raisons : > pour exécuter la machine JVM elle-même ; > pour exécuter les programmes Java résidant sur la machine JVM. Le langage Java se distingue également des autres langages de programmation par le fait que la spécification J2EE permet à un programmateur Java d'oublier la gestion de la mémoire. Dans les langages de programmation traditionnels, la gestion de la mémoire (allocation et «désallocation» appropriées de la mémoire) incombe au programmateur d'applications. Dans le cas du langage Java, cette tâche revient à la machine JVM. Celle-ci démarre avec une quantité initiale de mémoire allouée par le système d'exploitation hôte. On appelle parfois cette quantité de mémoire la taille du «tas». Cette taille initiale du tas ne correspond pas à la quantité de mémoire maximale disponible pour la machine Java, mais seulement à la quantité de mémoire dont cette machine dispose au démarrage. Au fil du temps, à mesure que les applications Java et que la machine Java elle-même ont besoin de davantage de mémoire (plus que la taille initiale du tas), la machine JVM intervient. Les servlets allouent davantage de mémoire (selon des quantités prédéfinies) à partir du système d'exploitation hôte. Il est important de contrôler le rythme auquel la machine Java alloue davantage de mémoire à partir du système d'exploitation hôte. Si cette allocation de mémoire n'est pas correctement gérée, le système d'exploitation hôte finira par manquer de mémoire. Un autre aspect important de la gestion du tas de mémoire concerne la quantité de mémoire libre disponible pour la machine Java. Il s'agit de la quantité de mémoire (généralement exprimée en Mo) du tas actuellement alloué que la machine Java peut encore utiliser. Cette mesure est importante car une fois que la machine Java manque de mémoire, elle risque de s'arrêter. Si cette valeur est de zéro, vous avez peut-être un problème avec la collecte des informations parasites (voir la rubrique consacrée à ce sujet ci-après) ou avec une application Java qui ne libère pas la mémoire/les objets (ce que l'on appelle souvent une fuite de mémoire). Comment déterminer le pourcentage actuel de mémoire utilisé dans la machine Java en fonction de la taille maximale "possible" du tas? Les machines JVM allouent de la mémoire constamment, mais seulement jusqu'à la taille maximale du tas. Cette dernière est spécifiée au démarrage de la machine Java et ne peut être modifiée pendant le fonctionnement de la machine. Il est donc important de connaître le pourcentage de mémoire utilisé en fonction de la taille maximale "possible" du tas. Il arrive que la taille du tas de la machine virtuelle Java augmente en raison d'une collecte insuffisante des informations parasites. La collecte des informations parasites est le processus de la machine 3

5 SERVLETS Java qui libère des portions de mémoire inutilisées et les réalloue au tas disponible. La machine virtuelle Java est chargée de collecter et de réutiliser la mémoire libre car la spécification J2EE libère le programmateur Java de cette tâche. La collecte des informations parasites est à la fois positive et négative. Elle est positive car elle octroie à la machine virtuelle Java davantage de mémoire pour le tas JVM. Elle est négative car la machine virtuelle Java a tendance à ralentir les transactions J2EE pendant la collecte des informations parasites. Dans ces conditions, la collecte des informations parasites devient un véritable "numéro d'équilibriste" ; si cette collecte n'est pas effectuée, la machine virtuelle Java risque de manquer de mémoire. En revanche, si la collecte des informations parasites intervient trop souvent ou demande trop de temps, vos applications Java sont ralenties. La durée de la collecte des informations parasites doit être courte au début et augmenter au fil du temps (cela est dû au fait que dans un premier temps, la machine virtuelle Java ne dispose pas de beaucoup de mémoire à libérer). En supposant que tout se passe bien dans la machine virtuelle Java, examinons les servlets. SERVLETS Les servlets contrôlent la transaction J2EE dans la machine virtuelle Java. Il est essentiel que leurs performances soient optimales pour la plupart (voire la totalité) des transactions dynamiques J2EE. Par exemple, de nombreux sites Web orientent toutes les transactions initiales vers un servlet de connexion. Si ce servlet a un problème au niveau du temps de réponse, chaque utilisateur qui se connecte au site Web rencontrera un temps de réponse lent. (N'oubliez pas que si le temps de réponse Web de votre site est lent, celui des sites Web concurrents est accessible d'un simple clic). De toute évidence, il est important de contrôler le temps de réponse de votre servlet, car un servlet donné pourrait attendre indéfiniment une ressource principale (de type base de données). Certains programmateurs Java peuvent ne pas concevoir de servlets dotés d'un temps d'attente limité avant expiration de la requête du servlet adressée à une base de données. En outre, si d'autres servlets accèdent à la même base de données qui ne répond pas, la machine JVM allouera une thread à chacun de ces servlets muets. En conséquence, la machine JVM pourrait commencer à manquer de thread. Cela aboutirait à une paralysie complète du site Web. En contrôlant le temps de réponse du servlet, vous pouvez prévenir un problème potentiel de ressources de fils dans la machine JVM..Enterprise Java Beans 6. Outre le contrôle du temps de réponse des servlets, vous devriez tenir compte du nombre de sessions Internet/requêtes traitées par chaque servlet. Ce nombre est important car si vous savez qu'un servlet donné transmet normalement les requêtes de manière continue (un servlet de connexion, par exemple) et que le nombre de requêtes passe à zéro, cela peut indiquer la présence d'un problème extérieur à la machine JVM (indiquant par exemple que le serveur HTTP manque d'écouteurs ou qu'une défaillance s'est produite au niveau du réseau). Cela peut aussi indiquer qu'un servlet est en attente à la suite d'une requête à une base de données principale. En supposant que tout se passe bien au niveau des servlets, examinons les EJB. ENTERPRISE JAVA BEANS Vous pouvez créer une application Web robuste sans EJB en utilisant votre serveur Web, des servlets et des JSP. Toutefois, si votre application requiert un accès à un corps central de logique métier et/ou un accès à de nombreuses bases de données principales, les EJB sont recommandés. Les EJB fournissent une couche d'abstraction entre vos applications Java et vos bases de données principales. Cette couche d'abstraction permet également la coordination de la logique métier pour vos applications Java. Cette couche est différente d'un servlet, dans la mesure où le servlet fournit uniquement la coordination pour la logique de programme d'une application Java. Les EJB doivent être aussi performants que les servlets en raison de leur rôle important dans la couche d'application J2EE. L'une des meilleures méthodes pour déterminer la santé globale des EJB consiste à surveiller le temps de réponse de chaque méthode (fonction) à l'intérieur de l'ejb. Ce temps est important car il indique le temps de réponse de tous les EJB (à l'exclusion du temps consacré à la création et à la suppression de beans). Un temps de réponse prolongé pourrait indiquer que le codage d'un servlet est défaillant. Ce servlet mal rédigé peut tenter d'accéder à un EJB (via ce que l'on appelle un bean d'entité), multipliant les appels pour satisfaire une seule requête à la base de données. Ces types de connexions de bean d'entité coûtent très cher en termes de performances. Un servlet mieux rédigé pourrait utiliser moins d'appels à l'ejb (via un bean de session) pour obtenir les mêmes informations de la base de données. Les EJB sont alloués à partir d'un pool au sein de la machine JVM. Chaque fois qu'un programme Java a besoin d'un EJB pour un objet, il accède au pool de beans. Vous devriez contrôler le nombre moyen d'objets présents dans le pool. Ce nombre est important car la taille du pool d'ejb dépend de deux variables : le nombre de beans et leur taille. Si votre pool de beans devient trop volumineux, vous 4

6 JAVA MESSAGE SERVICE devriez réduire la taille du tas. Vous pouvez envisager d'imposer une limite à la taille de votre pool EJB. Un EJB peut aussi appeler ce que l'on appelle un bean orienté message. Il s'agit de beans utilisés pour communiquer de manière asynchrone avec d'autres ressources. D'une manière générale, ces beans appellent le service JMS (Java Message Service). Examinons de plus près le service JMS. JAVA MESSAGE SERVICE Le JMS permet à une application Java de communiquer de manière asynchrone. Le JMS peut être utilisé avec les servlets comme avec les EJB. Dans les deux cas, les applications Java peuvent accéder à d'autres applications Java librement via la messagerie JMS. Le JMS peut transporter des messages de deux manières différentes : la première consiste à utiliser l'api JMS générique fournie par le cadre J2EE. Cet accès générique s'effectue via les fonctions de messagerie natives du JMS. L'autre méthode utilise également l'api JMS ; toutefois, les fonctions de messagerie sont remplies par un logiciel d'infrastructure tiers orienté messagerie tel que WebSphere MQ. Il existe un troisième moyen de transporter les messages J2EE, mais il ne fait pas partie du JMS. Cette méthode fait appel à une API tierce pour accéder directement au transport de messagerie en contournant le JMS. Parmi les difficultés que pose le JMS (et bien d'autres services de messagerie), on peut citer : > Mon message est-il arrivé à destination? > Où est mon message? > Quand mon message est-il arrivé à destination? En supposant que vos messages arrivent à destination via le JMS, vous pourriez vous demander comment sont gérées toutes ces ressources liées au J2EE. Examinons les interfaces de gestion J2EE disponibles. J2EE MANAGEMENT INTERFACE Toute interface de gestion ou technique d'administration implique un certain niveau d'intrusion dans le système. Ce niveau d'intrusion pourrait modifier considérablement les caractéristiques de fonctionnement de tout composant J2EE aboutissant à des mesures dépourvues de sens. Veuillez tenir compte de cet élément lorsque vous considérez l'une des trois approches suivantes pour la gestion J2EE : > Java Management Extensions (JMX) > Byte-Code Instrumentation > Java Profiler Interface (JVMPI) L interface JMX est l'approche la plus courante sur le marché et celle qui connaît l'essor le plus spectaculaire en matière de gestion J2EE. Elle facilite la gestion de toute application Java (à supposer que celle-ci soit compatible JMX). Cela signifie que l interface JMX peut gérer vos applications Java personnalisées ainsi que toute application tierce. Bon nombre de JVM courantes disposent ellesmêmes d'une interface JMX, ce qui permet à la machine Java ellemême d'être gérée via la JMX. Quels que soient les éléments gérés par l interface JMX, la gestion JMX est fournie via des «Management Beans» (MBeans). Soyez attentif à l'avenir à toute activité significative au niveau des interfaces JMX de la part des fournisseurs de machines Java et des ISV (fournisseurs de services Internet). L' «instrumentation byte-code» (Byte-Code Instrumentation) est une méthode utilisée pour insérer de manière dynamique des appels dans vos programmes Java. Ces appels extraient de manière dynamique des informations des programmes Java. Les informations extraites peuvent comprendre des détails à propos des instructions SQL, par exemple la quantité d'utilisation d'uc par instruction SQL. Comme l interface PMI, l'instrumentation byte-code dispose d'une marge de dépassement significative. La dernière approche de la gestion est celle de l interface JVMPI. Elle dispose de la marge de dépassement la plus importante de toutes les approches de gestion J2EE. Toutefois, l'interface contient des statistiques J2EE très granulaires telles que l'utilisation d'uc par la machine JVM et les statistiques relatives à la collecte des informations parasites. Compte tenu des dépassements extrêmes, cette approche de gestion ne devrait être utilisée que pour le développement et jamais dans la production. 5

7 Résumé et Conclusions. R É SUMÉ ET CONCLUSIONS Surveillez votre serveur d'application Java pendant quelques semaines afin de déterminer les hauts et les bas "normaux" de l'utilisation des ressources. Gardez un œil sur l'utilisation de la mémoire et vérifiez que la collecte des informations parasites est effectuée, mais pas de manière excessive. Vérifiez que vos servlets ne mettent pas trop longtemps à répondre aux requêtes en attente sur des fichiers. Les thread sont une ressource limitée ; assurez-vous que vos programmateurs Java les libèrent dans les délais impartis. Les EJB sont de plus en plus largement acceptés et de nombreuses entreprises ne maîtrisent pas encore totalement leur utilisation. N'oubliez pas qu'un EJB peut atteindre l'expiration de son délai comme un servlet attendant sur une ressource principale. En contrôlant les temps de réponse des EJB et des servlets, vous pouvez anticiper (et peut-être prévenir) la paralysie du site Web. Profitez d'une ou de plusieurs des approches de gestion Java évoquées dans cette présentation, par exemple les extensions de gestion Java, pour obtenir des informations de gestion détaillées. Bien qu'il existe plusieurs approches de ce type, celle qui convient à votre situation peut dépendre de différents facteurs tels que la conception des applications et la capacité du système. Java peut rendre vos applications modulaires et indifférentes aux plates-formes. Cela devrait maintenir les coûts de matériel et de développement dans des limites raisonnables et ramener les applications à un état productif plus rapidement. Si elles sont correctement gérées, ces applications peuvent aussi utiliser les ressources de manière efficace et fiable. Toutefois, le défi le plus important de la gestion de votre infrastructure J2EE consiste à assurer les niveaux de performances prévus. BMC Software fournit des solutions de gestion des applications qui automatisent le contrôle et l'optimisation de vos applications J2EE. Les solutions Java Application Management proposées par BMC Software vous aident à définir, mesurer et optimiser la qualité des services requis par vos applications Java et à gérer les éléments importants au niveau des services métier.1 POUR VOUS AIDER A GARDER L'AVANTAGE Les services professionnels de BMC Software aident votre entreprise à préserver ses atouts compétitifs grâce à une suite complète de services comprenant la gestion des niveaux de services, l installation, l implémentation, la configuration et la personnalisation. Nos offres professionnelles de services et de formations sont conçues pour assurer la disponibilité permanente des applications stratégiques, optimiser le potentiel du produit, réduire les risques liés aux projets, apporter une valeur informatique à votre activité et améliorer vos opérations. Pour en savoir plus sur les services professionnels de BMC Software, consultez le site 6

8 A PROPOS DE BMC SOFTWARE BMC Software, Inc. [NYSE: BMC], est un fournisseur leader en solutions de gestion d entreprise proposant une gestion de l informatique du point de vue de l entreprise. Les solutions BSM de BMC Software couvrent aussi bien les systèmes et les applications que les bases de données et la gestion des services. Fondée en 1980, BMC Software possède des bureaux dans le monde entier et a réalisé un chiffre d affaires de plus de 1,4 milliards de dollars en Pour plus d informations sur BMC Software, visitez le site Copyright 2004 BMC Software, Inc., en tant qu'œuvre non publiée. Tous droits réservés. BMC Software, les logos BMC Software et tous les autres noms de produits ou de services BMC Software sont des marques déposées de BMC Software, Inc. IBM est une marque déposée de International Business Machines Corporation. DB2 est une marque déposée de International Business Machines Corporation. Oracle est une marque déposée, et les noms de produit Oracle sont des marques déposées ou des marques commerciales de Oracle Corporation. Toutes les autres marques commerciales appartiennent à leurs détenteurs respectifs /05