IBM WebSphere Application Server, Advanced Edition
Guide d'optimisation des réglages
IBM WebSphere Application Server, Advanced EditionGuide d'optimisation des réglages |
|
Assistant d'optimisation des réglages de performances
Mise en cache des fragments dynamiques
Pour l'appeler à partir de la console d'administration, sélectionnez Console > Assistants > Optimiseur de performances.
Pour plus d'informations, consultez l'article 6.6.21 de l'InfoCenter.
Il s'agit de la capacité à mettre en cache la sortie des fichiers JSP et des servlets dynamiques. Cette technologie engendre une importante amélioration des performances de l'application. Cette mise en cache, qui fonctionne dans la JVM d'un serveur d'applications, intercepte les appels envoyés vers une méthode service() d'un servlet, vérifiant qu'elle peut servir l'appel à partir de la cache plutôt que d'exécuter à nouveau le servlet. Les applications J2EE ayant des taux élevés d'occupation et ne pouvant tolérer qu'un faible degré de latence dans le rafraîchissement de leurs données, la mise en cache des fragments peut permettre de réaliser d'importants gains en matière de temps de réponse du serveur, débit et évolutivité.
Lorsqu'un servlet a été exécuté (générant la sortie qui sera mise en cache), une entrée de cache est générée contenant cette sortie. Les effets secondaires de l'exécution (autrement dit, l'appel d'autres servlets ou JSP), ainsi que les métadonnées relatives à l'entrée incluant le délai d'expiration et les informations de priorité de l'entrée sont également générés. Les entrées uniques se distinguent par une chaîne d'ID générée à partir de l'objet HttpServletRequest pour chaque appel de servlet. Ceci résulte en un servlet mis en cache en fonction des paramètres de la demande, de l'URI utilisé pour appeler le servlet ou des informations de session. Comme les fichiers JSP sont compilés par WebSphere Application Server dans les servlets, les fichiers JSP et les servlets sont utilisés de manière interchangeable (sauf pour la déclaration des éléments dans un fichier XML).
Pour ce faire :
Pour plus d'informations consultez l'article 4.5: Mise en cache des fragments dynamiques de l'InfoCenter.
| Symptôme | Informations supplémentaires |
| Le débit et le temps de réponse ne sont pas acceptables. | Vitesse du processeur |
|
AIX : Erreur d'allocation de mémoire Solaris : Un nombre trop élevé de fichiers est ouvert | Descripteurs de fichiers AIX (ulimit) ou Descripteurs de fichiers Solaris (ulimit) |
| Solaris : Le serveur se bloque, les réponses prennent plusieurs minutes, l'utilisation du processeur reste élevée en raison de l'activité des processus du système et netstat indique que plusieurs sockets sont ouverts sur le port 80 et sont associés à l'état CLOSE_WAIT ou FIN_WAIT_2. | Solaris tcp_close_wait_interval/tcp_time_wait_interval et Solaris tcp_fin_wait_2_flush_interval |
| Windows NT/2000 : Netstat indique qu'un nombre trop élevé de sockets est associé à TIME_WAIT. | TcpTimedWaitDelay dans Windows NT/2000 |
| HP-UX 11 : Le débit n'est pas acceptable et la priorité du serveur d'applications n'a pas été adaptée. | Redéfinition de la priorité du système d'exploitation associée au processus WebSphere Application Server |
| En charge, les demandes du client n'arrivent pas au serveur Web car leur délai expire ou elle sont rejetées. |
Pour HP-UX 11, consultez Paramètres tcp_conn_request_max sous HP-UX 11 Pour IIS Windows NT/2000, consultez Paramètre ListenBackLog Pour IBM HTTP Server sous NT, consultez ListenBackLog |
| Windows NT/2000 : Les performances de WebSphere Application Server ont diminué après l'installation d'un serveur d'applications d'un autre fournisseur. | Autorisations d'accès à IIS |
| L'attribut percent maxed de Resource Analyzer indique que le pool des unités d'exécution du conteneur Web est trop petit. | Taille maximale de l'unité d'exécution du conteneur Web |
| Netstat affiche un nombre trop élevé de sockets dont l'état est TIME_WAIT pour le port 9080. | Nombre maximal de connexions maintenues actives pour le transfert du conteneur Web |
| Le nombre d'entrées-sorties sur disque est trop élevé en raison de la pagination. | Paramètres de taille de segment |
| L'attribut percent used de Resource Analyzer du pool de connexions de la source de données indique que la taille du pool est trop élevée. | Taille du pool de connexions de la source de données WebSphere |
| L'attribut prepared statement cache discards de Resource Analyzer indique que la taille de la mémoire cache de l'instruction préparée de la source de données est trop petite. | Taille de la cache des instructions préparées |
| Le nombre d'entrées-sorties sur disque est trop élevé en raison de l'enregistrement dans les journaux DB2. | DB2 MinCommit |
| L'attribut percent maxed de Resource Analyzer indique que le pool des unités d'exécution d'Object Request Broker est trop petit. | Mise en file d'attente et beans enterprise |
| L'interface JVMPI (Java Virtual Machine Profiler Interface) de Resource Analyzer indique une utilisation excessive d'objets lorsqu'un temps trop élevé est consacré à la récupération de place. | Détection d'une utilisation excessive d'objets |
| L'attribut used memory de Resource Analyzer indique les fuites de mémoire et une exception Java Out of Memory (Mémoire insuffisante) est signalée. | Détection des fuites de mémoire |
| Le débit, le temps de réponse et l'évolutivité ne sont pas acceptables. | Si l'application le permet, exploitez la mise en mémoire cache pour le fragment dynamique |
De nombreuses améliorations peuvent être apportées à WebSphere Application Server à l'aide des procédures d'optimisation des réglages. Ce guide d'optimisation des réglages explique comment optimiser les travaux et contient des recommandations générales et
une description des méthodes spécifiques d'optimisation des réglages. Vous trouverez également des astuces et des conseils relatifs aux différents facteurs et variables pouvant améliorer les performances.
Utilisez le guide avec les exemples et les ressources pour accroître vos connaissances sur l'optimisation des réglages. L'optimisation des performances est un domaine en constante évolution, car elle s'appuie sur l'expérience acquise au fil du temps. Les résultats peuvent être différents de ceux indiqués dans ce guide.
Pour une grande diffusion, certaines procédures sont décrites pour la définition des paramètres dans d'autres produits. Ces produits pouvant être sujets à modification, les procédures doivent être considérées uniquement comme des suggestions.
Il existe deux types de réglage possibles : l'optimisation des performances de l'application et l'optimisation des paramètres.
Bien que l'optimisation des réglages de l'application offre parfois les améliorations les plus importantes, l'objectif de ce document est de présenter les paramètres de performances individuelles, ainsi que la synergie entre ces différents paramètres de performance.
Le livre blanc intitulé WebSphere Application Server Development Best Practices for Performance and Scalability traite de l'optimisation des réglages de performance et décrit les meilleures méthodes de développement pour les applications contenant des servlets, des fichiers JSP (Java Server Pages), des connexions JDBC (Java Database Connectivity) et pour les applications d'entreprise contenant des composants de beans enterprise.
Le tableau ci-après répertorie les différents paramètres permettant l'optimisation des réglages en vue de l'amélioration des performances.
Les paramètres ci-après permettent d'éviter des problèmes fonctionnels.
| Paramètre ListenBackLog : S'applique si Windows NT/2000 s'exécute avec IIS en cas de charge client importante. |
| Type de transport : Utilisez les sockets INET sous Solaris (valeur par défaut pour WebSphere Application Server) |
| Nombre de connexions à DB2 : Si vous établissez un nombre de connexions supérieur à celui défini par défaut par DB2. |
| L'option Admission d'allocation d'unité d'exécution au delà du maximum a été sélectionnée et le système est surchargé car le nombre d'unités d'exécution attribué est trop élevé. |
| Utilisation des sockets TCP pour DB2 sous Linux : pour les bases de données locales |
| Taille du pool de connexions de la source de données WebSphere : Vérifiez que vous disposez d'assez de connexions pour gérer les connexions supplémentaires requises par le traitement des transactions avec des EJB entity et pour éviter les blocages. |
WebSphere Application Server comporte une série de composants étroitement liés les uns aux autres qui doivent être soigneusement réglés pour prendre en charge les besoins propres de votre application d'e-business de bout en bout. Les réglages décrits ci-après permettent d'obtenir le meilleur débit tout en préservant la stabilité globale du système.
WebSphere Application Server s'appuie sur un réseau de files d'attente interconnectées qui représentent les divers composants de la plateforme de service d'applications. Ces files d'attente comprennent le réseau de communication, le serveur Web, le conteneur d'EJB, la source de données et, éventuellement, un gestionnaire de connexions vers un système dorsal personnalisé. Chacune de ces ressources représente une file dans laquelle sont placées les demandes en attente d'utilisation de cette ressource.
Les files d'attente de WebSphere sont des ressources qui dépendent de la charge. Le temps moyen de service d'une demande dépend du nombre de clients concurrents.
La plupart des files d'attente qui constituent le réseau de mise en file d'attente sont des files d'attente fermées. Par opposition à une file d'attente ouverte, une file d'attente fermée impose une limite au nombre de demandes qui peuvent coexister dans la file.
Une file fermée permet une gestion étroite des ressources du système. Par exemple, dans les propriétés du conteneur Web, le paramètre Nombre maximal de connexions détermine la taille de la file d'attente associée au conteneur Web. Si les servlets s'exécutant dans conteneur Web créent en moyenne 10 Mo d'objets au cours de chaque demande, l'attribution de la valeur 100 au paramètre max connections (Nombre maximal de connexions) limite à 1 Go la quantité de mémoire consommée par le conteneur Web.
Dans une file d'attente fermée, une demande peut prendre l'un des deux états suivants : active ou en attente. Une demande active est soit en train d'effectuer un travail, soit en attente d'une réponse d'une file d'attente en aval. Par exemple, au niveau du serveur Web, une demande active peut soit effectuer une opération telle que la récupération d'un contenu HTML statique, soit attendre qu'une demande soit satisfaite au niveau du conteneur Web. On dit d'une demande qu'elle est en attente lorsqu'elle attend de devenir active. Elle reste à l'état en attente jusqu'à ce que l'une des demandes actives quitte la file.
Tous les serveurs Web reconnus par WebSphere sont des files d'attente fermées, comme le sont les sources de données WebSphere. Les conteneurs Web peuvent être configurés comme files d'attente ouvertes ou fermées. En règle générale, il est préférable qu'ils soient des files d'attente fermées. Les conteneurs d'EJB sont des files d'attente ouvertes. Si aucune unité d'exécution n'est disponible dans le pool, il en est créé une nouvelle pour la durée de la demande.
Si des beans enterprise sont appelés par des servlets, le conteneur Web limite le nombre total de demandes émises simultanément à destination du conteneur d'EJB, car ce conteneur possède aussi une limite (il s'agit d'une file fermée). Cependant, cette protection n'est efficace que dans la mesure où des beans enterprise sont appelés à partir de l'unité d'exécution du servlet. Rien ne vous empêche de créer des unités d'exécution et d'envoyer de nombreuses demandes au conteneur d'EJB. C'est pourquoi il vaut mieux éviter que le servlet crée ses propres unités d'exécution.
La partie ci-après présente les différentes définitions de file d'attente.
La section suivante décrit une méthodologie de configuration des files d'attente de WebSphere Application Server. Vous pouvez changer la dynamique du système et par conséquent, ses performances, en déplaçant des ressources (par exemple en transférant le serveur de base de données sur une autre machine) ou en augmentant la puissance des ressources, par exemple en équipant le système de processeurs plus rapides avec plus de mémoire). Par conséquent, adaptez les paramètres de réglage à une configuration spécifique de l'environnement de production.
La première règle à suivre en matière d'optimisation des réglages est de minimiser le nombre de demandes en attente au niveau des composants de WebSphere Application Server. En général, mieux vaut que les demandes attendent dans le réseau (en amont du serveur Web) que dans WebSphere Application Server. Ainsi, seules les demandes prêtes à être traitées sont autorisées à pénétrer dans le réseau de mise en file d'attente. Pour réaliser cette configuration, il faut que les files d'attente les plus en amont (les plus proches du client) soient légèrement plus grandes et que celles les plus en aval (les plus éloignées du client) soient de plus en plus petites.
Les files d'attente du réseau se réduisent peu à peu à mesure que les demandes progressent vers l'aval. Lorsque 200 clients accèdent au serveur Web, 125 demandes restent en attente au niveau du réseau de communication car le serveur Web est configuré pour accepter jusqu'à 75 clients concurrents. Les 75 demandes doivent ensuite être transmises du serveur Web au conteneur Web, mais 25 d'entre elles restent en attente au niveau du serveur Web, les 50 autres étant prises en charge par le conteneur Web. Les demandes passent ensuite à travers la source de données ; seules 25 d'entre elles parviennent à la destination finale, le serveur de bases de données. Comme à tout moment, un travail en amont attend de pouvoir être pris en charge par un composant, aucun des composants du système ne marque de temps d'arrêt. Les demandes attendent d'être servies sur le réseau, en dehors de WebSphere Application Server. Cela augmente la stabilité car aucun composant n'est surchargé. Dans un cluster WebSphere Application Server, les utilisateurs en attente peuvent également être aiguillés vers d'autres serveurs via un logiciel de routage tel qu'IBM Network Dispatcher.
A l'aide d'un scénario de test représentatif de l'application de production (testant, par exemple, toutes les parties de code significatives), ou à l'aide de l'application elle-même, procédez à une série d'expérimentations pour déterminer le point de saturation du système, c'est-à-dire à quel moment ses capacités sont sollicitées au maximum. Vous devez avoir préalablement éliminé la plupart des goulets d'étranglement de l'application. Généralement, l'objectif de ces essais est d'amener les processeurs à leur limite d'utilisation (c'est-à-dire à près de 100 % de leur capacité).
Pour définir la ligne de base de l'expérimentation, commencez par un essai avec de grandes files d'attente. Le nombre de demandes concurrentes dans le système est ainsi maximal. Par exemple, faites un premier essai avec une taille de file d'attente de 100 pour chacun des serveurs rencontrés sur le parcours WebSphere, c'est-à-dire le serveur Web, le conteneur Web et la source de données.
Exécutez ensuite une série d'essais pour tracer une courbe de débit, en augmentant la charge (nombre d'utilisateurs concurrents) après chaque essai. Par exemple, commencez avec un seul utilisateur, puis passez à deux utilisateurs, puis à 5, 10, 25, 50, 100, 150 et 200. Après chaque essai, consignez le débit mesuré (demandes par seconde) et les temps de réponse (secondes par demande).
La courbe de débit résultant de ces essais doit ressembler à la courbe ci-dessous.
Le débit de WebSphere Application Server est fonction du nombre de demandes concurrentes présentes dans l'ensemble du système. Dans la section A, qui est la zone de faible charge, le débit augmente presque linéairement avec le nombre de demandes concurrentes. Cela montre que tant que la charge est modérée, les demandes concurrentes rencontrent très peu d'encombrements au sein des files d'attente système de WebSphere Application Server. A un certain point, les encombrements commencent à se développer. Le débit continue à augmenter, mais avec une pente beaucoup plus faible, jusqu'à ce qu'il atteigne un point de saturation qui représente la valeur de débit maximale. Ce point de saturation est dû à la formation d'un goulet d'étranglement dans le système WebSphere Application Server. Le type de goulot le plus facile à gérer résulte de la saturation des processeurs des machines WebSphere Application Server. En effet, pour y remédier, il suffit d'ajouter d'autres processeurs ou de remplacer les processeurs existants par des modèles plus puissants.
Dans la zone de forte charge ou dans la section B, alors que la charge du client concurrent augmente, le débit reste relativement identique. Toutefois, le temps de réponse augmente proportionnellement à la charge de l'utilisateur. Autrement dit, si le nombre d'utilisateurs est doublé dans la zone de forte charge, le temps de réponse double également. A un certain point, qui marque le début de la section C, la zone de dégradation, l'un des composants du système, approche de la saturation et le débit commence à chuter. Ce point peut être atteint, par exemple, lorsque le nombre de connexions réseau au niveau du serveur Web dépasse les limites de la carte réseau, ou en cas de franchissement des limites du système d'exploitation en termes de descripteurs de fichier.
Si le point de saturation est atteint en poussant l'utilisation des processeurs du système à près de 100 % de leur capacité, passez à l'étape suivante. Si le point de saturation a été atteint sans que les processeurs en soit la cause, il est probable qu'un goulet d'étranglement se soit formé ailleurs et qu'il soit aggravé par l'application. Par exemple, l'application peut créer des objets Java de façon excessive, provoquant des goulets d'étranglement au niveau de la récupération de place dans le processus Java.
Il existe deux façons de gérer des goulets d'étranglement : supprimer le goulet d'étranglement ou le cloner. La meilleure façon de gérer un goulet d'étranglement est de le supprimer. A cet effet, utilisez un "profileur" d'applications Java pour déterminer comment et dans quelles proportions l'application utilise les objets Java. Vous pouvez utiliser des profileurs tels que Performance Trace Data Visualizer(PTDV), JProbe et Jinsight.
Le nombre d'utilisateurs concurrents relevé au point de saturation du débit représente la capacité maximale de l'application en termes de concurrence des accès. Par exemple, si lors des essais précédents, le point de saturation de WebSphere Application Server a été atteint avec 50 utilisateurs concurrents, il est possible que la meilleure combinaison débit/temps de réponse soit obtenue avec 48 utilisateurs. Cette valeur est appelée la limite de concurrence de l'application. Elle représente la valeur à utiliser comme base pour l'ajustement des files d'attente système de WebSphere Application Server. Rappelons que la plupart des demandes d'utilisateur doivent de préférence rester en attente en dehors de WebSphere Application Server, c'est-à-dire au niveau du réseau de communication. Vous devez donc diminuer la taille des files d'attente à mesure que vous progressez vers l'aval. Par exemple, si l'on admet que la limite de concurrence de l'application s'établit à 48, adoptez les valeurs de départ suivantes pour les files d'attente système : 75 pour le serveur Web, 50 pour le conteneur Web et 45 pour la source de données. Effectuez d'autres séries d'essais en augmentant et en réduisant légèrement ces valeurs pour trouver les meilleurs paramètres.
Resource Analyzer peut être utilisé pour déterminer le nombre d'utilisateurs concurrents via le nombre d'unités d'exécution actives simultanément du pool d'unités d'exécution du moteur de servlet.
Lors de l'optimisation des performances, le débit augmente de 10 à 15 % lorsque le nombre maximal de connexions maintenues actives pour le transfert est adapté au nombre maximal d'unités d'exécution de conteneurs Web.
Dans de nombreux cas, seule une fraction des demandes passant à travers une file donnée entre ensuite dans la file en aval. Dans le cas d'un site présentant de nombreuses pages statiques, nombre de demandes sont traitées intégralement par le serveur Web sans jamais être transmises au conteneur Web. Dans ces circonstances, la file d'attente du serveur Web peut donc être nettement plus grande que celle du conteneur Web. Ainsi, dans la section précédente, la taille de la file d'attente du serveur Web a été réglée à 75 au détriment d'une valeur proche de la limite de concurrence de l'application (48). Des ajustements comparables s'imposent lorsque les divers composants de la chaîne WebSphere possèdent des temps d'exécution différents.
Par exemple, dans une application dont 90 % du temps d'exécution est monopolisé dans un servlet complexe, le reste du temps étant consacré à l'exécution d'une courte requête JDBC, en moyenne, seuls 10 % des servlets utilisent simultanément des connexions à la base de données. La file d'attente de connexion à la base de données peut donc être beaucoup plus petite que celle du conteneur Web. Inversement, si une grande part du temps d'exécution d'un servlet est consacré à une requête complexe sur la base de données, il faut envisager d'augmenter la taille des files d'attente tant au niveau du conteneur Web qu'au niveau de la source de données. Surveillez toujours le taux d'utilisation des processeurs et de la mémoire à la fois sur le serveur WebSphere Application Server et sur le serveur de bases de données afin d'éviter que le processeur ou la mémoire ne saturent.
Les appels de méthodes vers les beans enterprise ne sont mis en file d'attente qui si le client qui émet l'appel est à distance. Exemple : si le client EJB est en cours d'exécution dans une machine virtuelle Java distincte (c'est-à-dire un autre espace adresse) de celle où s'exécute le bean enterprise. En revanche, si le client d'EJB (un servlet ou un autre bean enterprise) s'exécute dans la même JVM, la méthode appelée s'exécute dans la même unité d'exécution que le client et l'appel n'est pas mis en file d'attente.
Les beans enterprise distants communiquent à l'aide du protocole RMI/IIOP. Les appels de méthodes adressés via ce protocole sont traités par un ORB du côté serveur. Le pool d'unités d'exécution agit comme file d'attente pour les demandes entrantes. Cependant, si une demande de méthode éloignée est émise et qu'aucune unité d'exécution n'est disponible dans le pool, une nouvelle unité d'exécution est créée. Une fois la demande de méthode terminée, l'unité d'exécution est supprimée. Ainsi, lorsque l'ORB est utilisé pour traiter les demandes de méthode éloignées, le conteneur d'EJB est une file d'attente ouverte car l'utilisation des unités d'exécution n'est pas liée. L'illustration suivante décrit les deux options de mises en file d'attente de beans enterprise.
Lors de la configuration du pool d'unités d'exécution, il est important de connaître les schémas d'appel du client d'EJB. Si un servlet effectue un petit nombre d'appels aux beans enterprise éloignés et que chaque appel de méthode est relativement rapide, envisagez de définir le nombre d'unités d'exécution du pool ORB inférieur à la valeur de la taille du pool d'unités d'exécution du conteneur Web.
Resource Analyzer indique un paramètre appelé Taux d'utilisation maximale qui détermine la durée pendant laquelle les unités d'exécution configurées sont utilisées. Si cette valeur comporte toujours deux chiffres, alors le composant ORB peut se transformer en goulet d'étranglement et le nombre d'unités d'exécution doit être augmenté.
Le degré selon lequel vous devez augmenter la valeur du pool d'unités d'exécution ORB est fonction du nombre de servlets simultanés (autrement dit, des clients) appelant les beans enterprise et de la durée de chaque appel de méthode. Si les appels de méthode sont plus longs, envisagez de modifier la taille du pool d'unités d'exécution de l'ORB de telle sorte qu'elle soit égale à la taille du conteneur Web, car il y a peu d'imbrication des appels de méthode éloignés. Si le servlet n'effectue que des appels de courte durée ou rapide vers l'ORB, le pool d'unités d'exécution de l'ORB peut être de petite taille. Potentiellement, plusieurs servlets peuvent réutiliser la même unité d'exécution ORB. Dans ce cas, le pool d'unités d'exécution ORB peut être de petite taille, voire même la moitié de la taille du pool d'unités d'exécution définie pour le conteneur Web. Si l'application passe beaucoup de temps dans l'ORB, configurez une relation plus régulière entre le conteneur Web et l'ORB.
La possibilité de cloner les serveurs d'applications peut être très utile à la configuration d'environnements de production à fort potentiel d'évolution. Cette remarque est particulièrement vraie lorsque l'application présente des goulets d'étranglement qui empêchent d'exploiter toute la puissance des serveurs multiprocesseurs (SMP). Au moment de choisir la taille des files d'attente système de WebSphere Application Server dans une configuration en cluster, n'oubliez pas que l'ajout d'un serveur à un cluster double la charge du serveur en aval.
Deux clones de conteneur Web sont insérés entre un serveur Web et une source de données. Supposons que le serveur Web, les deux clones du moteur de servlet et la source de données (mais pas la base de données) s'exécutent tous sur un même serveur physique SMP. Compte tenu de ces éléments, les points suivants sont à prendre en considération :
Un établissement de liaison SSL survient lorsqu'une connexion SSL est établie. Une fois la connexion établie, SSL procède à un chiffrement et à un déchiffrement en bloc pour chaque opération de lecture-écriture. Le coût de performances d'un établissement de connexion SSL est plus élevé que celui d'un chiffrement et d'un déchiffrement en bloc.
Afin d'améliorer les performances SSL, le nombre de connexions SSL individuelles et le nombre d'établissements de connexions doivent être réduits.
La réduction du nombre de connexions augmente les performances liées aux communications sécurisées via les connexions SSL, ainsi que les communications non sécurisées via des connexions TCP simples. L'une des façons de réduire le nombre de connexions SSL individuelles est d'utiliser un navigateur prenant en charge HTTP 1.1. La réduction du nombre de connexions SSL individuelles peut être impossible pour certains utilisateurs s'ils ne peuvent pas mettre à niveau HTTP 1.1.
Il est plus courant de réduire le nombre de connexions (à la fois TCP et SSL) entre deux composants WebSphere Application Server. Les instructions suivantes permettent de garantir que le transfert HTTP du serveur d'applications est configuré de sorte que le plug-in du serveur Web n'ouvre pas plusieurs fois de nouvelles connexions au serveur d'applications :
Les accélérateurs matériels actuellement pris en charge par WebSphere Application Server augmente simplement les performances de l'établissement de connexions et non le chiffrement/déchiffrement en bloc. En général, un accélérateur est avantageux uniquement pour le serveur Web car les connexions du serveur Web sont à court-terme. Toutes les autres connexions SSL de WebSphere Application Server sont des connexions à long-terme : ces connexions ne sont pas avantagées par un dispositif matériel qui accélère uniquement l'établissement des connexions SSL.
Les performances d'un algorithme de chiffrement n'est pas le même pour le logiciel et pour le matériel. Le fait qu'une suite de chiffrement est plus efficace dans le logiciel ne signifie pas qu'elle le sera pour le matériel. En général, certains algorithmes ne fonctionnent pas pour le matériel (exemple : DES et 3DES). Toutefois, du matériel spécialisé peut fournir des implémentations efficaces de ces mêmes algorithmes.
Les performances du chiffrement et du déchiffrement en bloc sont affectées par l'algorithme de chiffrement utilisée pour une connexion SSL individuelle. Le logiciel test permettant de calculer les données a utilisé IBM JSSE pour le logiciel du serveur et le logiciel du client, mais n'a pas utilisé de support matériel de chiffrement. Le test n'a pas inclus le temps nécessaire à l'établissement d'une connexion, mais le temps nécessaire à la transmission des données via une connexion établie. Par conséquent, les données révèlent les performances SSL relatives de différents algorithmes de chiffrement pour les connexions à long-terme.
Avant d'établir une connexion, le client a activé un algorithme de chiffrement unique pour chaque scénario de test. Une fois la connexion établie, le client détermine le temps nécessaire à l'écriture d'un entier sur le serveur ainsi que le temps nécessaire au serveur pour enregistrer le nombre spécifié d'octets sur le client. Le fait de varier la quantité de données n'a eu que des effets négligeables sur les performances relatives des algorithmes de chiffrement. Le graphique ci-dessous indique les performances de chaque algorithme de chiffrement.
L'analyse des données ci-dessus révèle les points suivants :
La liste de vérification contient les paramètres suivants :
L'option de validation A permet des performances de bean enterprise maximales en mettant en cache les données de base de données hors de la portée de la transaction. En général, elle est applicable uniquement lorsque le conteneur EJB dispose d'un accès exclusif à la base de données précisée. Sinon, l'intégrité des données est compromise. L'option de validation B permet une mise en cache plus agressive des instances d'objets d'EJB entity, ce qui peut améliorer les performances de l'option de validation C, mais utilise aussi une mémoire plus importante. L'option de validation C correspond à la configuration réelle la plus courante pour les EJB entity.
La configuration des propriétés Activation et Chargement sur détermine les options de validation utilisées.
Le niveau d'isolement joue également un rôle considérable en terme de performances. Des niveaux d'isolement élevés réduisent les performances en augmentant le verrouillage de lignes et la surcharge de la base de données tout en diminuant le nombre d'accès concurrents aux données. Le comportement des bases de données varie selon les paramètres d'isolement. En général, le paramètre Lecture pouvant être répétée est adapté aux bases de données DB2. Lecture validée est souvent utilisé pour Oracle. Oracle ne prend pas en charge le paramètre Lecture pouvant être répétée et le convertira en niveau d'isolement sérialisable le plus élevé.
Le niveau d'isolement peut être spécifié au niveau du bean ou de la méthode. Par conséquent, il est possible de configurer différents paramètres d'isolement pour diverses méthodes. Cette possibilité est avantageuse lorsque certaines méthodes requièrent un isolement plus élevé que d'autres, et permet d'atteindre un niveau de performances optimal tout en conservant les conditions d'intégrité. Toutefois, l'isolement ne peut pas changer entre deux appels de méthode dans une transaction de bean enterprise précise. Une exception d'exécution sera générée dans ce cas.
Lecture pouvant être répétée
Ce niveau interdit les lectures de lignes modifiées et les lectures non reproductibles, mais autorise les lectures
fantômes.
Lecture validée
Ce niveau interdit les lectures de lignes modifiées, mais autorise les lectures non reproductibles et les lectures
fantômes.
Lecture non validée
Ce niveau autorise les lectures de lignes modifiées, les lectures non reproductibles et les lectures fantômes.
Le conteneur utilise l'attribut de niveau d'isolement des transactions de la manière suivante :
Si le client appelle une méthode de bean depuis l'extérieur d'un contexte de transaction, le conteneur se comporte comme si l'attribut de transaction Not supported était sélectionné. Le client doit appeler la méthode sans contexte de transaction.
Mandatory (Obligatoire)
Cette valeur indique au conteneur de toujours appeler la méthode du bean dans le contexte de transaction associé au client. Si le
client tente d'appeler la méthode du bean sans contexte de transaction, le conteneur renvoie l'exception
javax.jts.TransactionRequiredException au client. Le contexte de transaction est transmis à tout objet bean enterprise ou ressource enterprise
auquel une méthode de bean enterprise accède.
Les clients de bean enterprise qui accèdent à ces beans entity doivent le faire dans une transaction existante. Pour d'autres beans enterprise, le bean enterprise ou la méthode de bean doit implémenter la valeur Gérée par bean ou utiliser la valeur Requise ou Requiert un nouvel élément. Pour les clients EJB autres que les beans enterprise, le client doit appeler une transaction à l'aide de l'interface javax.transaction.UserTransaction.
Requires New (Requiert un nouvel élément)
Cette valeur indique au conteneur de
toujours appeler la méthode de bean à l'intérieur d'un nouveau
contexte de transaction, peu importe que le client appelle la méthode à
l'intérieur ou à l'extérieur d'un contexte de transaction. Ce contexte de transaction est transmis à tout objet ou ressource de bean
enterprise utilisé par cette méthode du bean.
Required (Requis)
Cette valeur indique au conteneur d'appeler la méthode du bean dans un contexte de transaction. Si un client appelle une méthode du
bean dans un contexte de transaction, le conteneur appelle la méthode dans le contexte de transaction du client. Si un client appelle une méthode de
bean à l'extérieur d'un contexte de transaction, le conteneur crée un
nouveau contexte de transaction et appelle la méthode de bean depuis
ce contexte. Ce contexte de transaction est transmis à tout objet ou ressource de bean
enterprise utilisé par cette méthode du bean.
Supports (Prend en charge)
Cette valeur indique au conteneur d'appeler la méthode du bean dans un contexte de transaction lorsque le client l'appelle dans un
contexte de transaction. Si le client appelle la méthode du bean sans contexte de transaction, le conteneur l'appelle de la
même manière. Ce contexte de transaction est transmis à tout objet ou ressource de bean
enterprise utilisé par cette méthode du bean.
Not Supported (Non pris en charge)
Cette valeur indique au conteneur d'appeler les méthodes du bean sans contexte de transaction. Si un client appelle une méthode du
bean dans un contexte de transaction, le conteneur suspend l'association entre la transaction et l'unité d'exécution en
cours avant d'appeler la méthode sur l'instance du bean enterprise. Le conteneur rétablit ensuite l'association lorsque le
contrôle lui est rendu après l'appel de méthode. Le contexte de transaction suspendu n'est pas transmis aux objets
ou ressources de bean enterprise utilisés par cette méthode du bean.
Bean Managed (Gérée par bean)
Cette valeur indique au conteneur que la classe du bean gère directement la délimitation des transactions. Cette propriété
peut uniquement être spécifiée pour les beans session et non
pour des méthodes de bean individuelles.
L'examen de la récupération de place Java peut révéler comment l'application utilise la mémoire. La récupération de place est une force Java. Le développeur étant soulagé de la partie gestion de la mémoire, les applications Java sont plus robustes que celles qui sont écrites dans d'autres langages où la récupération de place n'est pas prévue. L'application ne doit cependant pas abuser des objets. Dans une application fonctionnant correctement, il est normal que le processus de récupération de place consomme de 5 à 20 % du temps total d'exécution. Mais s'il n'est pas géré, ce processus peut vite devenir l'un des plus gros goulets d'étranglement d'une application, en particulier sur les machines serveur SMP.
La récupération de place peut servir à évaluer les performances de l'application. En analysant les données recueillies au cours de l'exécution d'une charge fixe, les utilisateurs déterminent si l'application utilise un nombre excessif d'objets. La récupération de place peut même servir à détecter la présence de fuites de mémoire.
La récupération de place et les statistiques de segment de Resource Analyzer peuvent servir à évaluer les performances de l'application. Vous pouvez détecter les fuites de mémoire et l'utilisation excessive d'objets en surveillant l'opération de récupération de place.
Pour ce type de recherche, définissez la même valeur pour les tailles minimale et maximale du segment. Choisissez une charge de travail répétitive représentative, correspondant autant que possible à la production (erreurs utilisateur, etc). Il est également important de permettre à l'application de s'exécuter pendant plusieurs minutes jusqu'à ce que son état soit stabilisé.
Pour obtenir des statistiques pertinentes, exécutez la charge fixe jusqu'à ce l'état de l'application soit stabilisé. En général, cette opération prend quelques minutes.Pour savoir si l'application utilise un trop grand nombre d'objets, consultez les compteurs pour profileurs JVMPI dans Resource Analyzer. L'intervalle moyen entre les appels de récupération de place doit être 5 à 6 fois la durée moyenne d'une seule opération de récupération de place. Dans le cas contraire, l'application passe plus de 15 % de son temps en récupération de place. Aussi, observez le nombre d'objets libérés, alloués et déplacés.
Si les valeurs observées démontrent qu'il y a un goulet d'étranglement, il existe deux remèdes possibles à cette situation. Le moyen le plus simple et le plus efficace est d'optimiser l'application en y implémentant des caches et des pools d'objets. Utilisez un profileur Java pour déterminer quels objets sont concernés. Si l'application ne peut pas être optimisée, l'ajout de mémoire, de processeurs et de clones peut aider. Le surcroît de mémoire permet à chaque clone de disposer d'une taille de segment Java raisonnable. Quant aux processeurs supplémentaires, ils permettent aux clones de fonctionner en parallèle.
Dans les applications Java, les fuites de mémoire contribuent dangereusement aux goulets d'étranglement causés par la récupération de place. Elles font plus de dégâts que l'utilisation excessive de mémoire, car elles finissent par entraîner une instabilité du système. Au fil du temps, la récupération de place intervient plus fréquemment, puis le segment Java finit par s'épuiser et Java échoue sur une exception de type Mémoire insuffisante (Out of Memory). Les fuites de mémoire se produisent lorsqu'un objet qui n'est plus utile possède encore des références qui ne sont jamais supprimées. Cela arrive le plus souvent dans les classes de collection telles que Hashtable, car la table elle-même contient toujours une référence à l'objet, même lorsque les références réelles à cet objet ont été supprimées.
Il arrive souvent que les applications se ferment immédiatement après avoir été déployées dans l'environnement de production. Une charge de travail élevée en est souvent la cause. Tel est le cas pour les applications perdant des ressources, pour lesquelles une charge de travail élevée amplifie les fuites et provoque l'échec de l'allocation de mémoire.
Le test des fuites de mémoire est lié à l'augmentation des chiffres. Les fuites de mémoire sont mesurées en octets ou en kilo-octets dont la place ne peut pas être récupérée. Il s'agit de faire la différence entre ces quantités et les tailles attendues pour la mémoire utile et inutilisable. Cette tâche est plus facile à réaliser si les chiffres sont élevés, ce qui entraîne des écarts plus grands et permet une identification facile des incohérences. La liste ci-dessous est la liste des points importants relatifs aux fuites de mémoire.
Vous pouvez procéder à des tests de répétition au niveau du système ou au niveau du module. Un test modulaire permet un meilleur contrôle. Lorsqu'un module est conçu de sorte que tout ce qui est effectué dans le module reste confidentiel et ne créé aucun effet secondaire externe y compris au niveau de l'utilisation de mémoire, le test des fuites de mémoire peut être beaucoup plus facile. Tout d'abord, l'utilisation de la mémoire avant l'exécution du module est enregistrée et un ensemble déterminé de scénarios de test est exécuté à plusieurs reprises. Une fois le test exécuté, l'utilisation de mémoire courante correspond à plusieurs fois celle enregistrée et vérifiée précédemment, si elle a changé de façon significative. N'oubliez pas que vous devez lancer vous-même la récupération de place lors de l'enregistrement de l'utilisation de mémoire courante. Pour ce faire, insérez System.gc() dans le module dans lequel vous voulez procéder à la récupération de place ou utilisez un outil de profilage qui force l'événement.
Prenez en compte les points ci-après lors de la sélection des scénarios de test à utiliser pour le test des fuites de mémoire.
Resource Analyzer permet de déterminer si l'application présente des fuites de mémoire. Pour de meilleurs résultats, répétez l'essai en augmentant à chaque fois la durée, 1000, 2000 ou 4000 demandes de page, par exemple. La courbe Resource Analyzer de la mémoire utilisée doit être en dent de scie. Chaque point de la courbe correspond à une opération de récupération de place. Votre application présente une fuite de mémoire dans les cas suivants :
Si la consommation du segment indique une éventuelle fuite lors d'une charge de travail élevée (le serveur d'application utilise constamment près de 100 % de la CPU), mais que le segment semble récupérer lors d'une charge de travail plus faible ou presque inexistante, cela indique une fragmentation de segment. La fragmentation du segment survient lorsque la JVM peut libérer suffisamment d'objets pour satisfaire les demandes d'allocation de mémoire lors des cycles de récupération de place, mais qu'elle n'a pas le temps de comprimer de petites zones de mémoire libre du segment dans des espaces contigus plus grands.
Une autre forme de fragmentation de segment survient lorsque de petits objets (moins de 512 octets) sont libérés. Les objets sont libérés mais le stockage n'est pas récupéré, ce qui entraîne la fragmentation de la mémoire.
La fragmentation du segment peut être évitée si vous activez l'indicateur -Xcompactgc dans les arguments de lignes de commande des paramètres avancés de la JVM. -Xcompactgc garantit que chaque cycle de récupération de place évite la fragmentation, avec une perte de performances minime.
Les paramètres du segment Java influencent le comportement du processus de récupération de place. L'augmentation de la taille des segments permet de créer plus d'objets. Du fait qu'un segment de grande taille met plus de temps à se remplir, l'application dispose d'une autonomie plus importante et les opérations de récupération de place sont moins fréquentes. Cependant, plus la taille du segment est importante, plus il faut de temps pour le compacter. Chaque opération de récupération de place prend aussi plus de temps.
L'illustration représente trois profils d'utilisation des processeurs. La charge de travail est la même pour les trois profils, mais chacun reflète un paramétrage différent du segment Java. Pour le profil du milieu, les paramètres sont équivalents à la taille initiale et maximale du segment ou à 128 Mo. Il existe quatre opérations de récupération de place. Le temps total passé à récupérer de la place est égal à environ 15 % du temps total d'exécution de l'essai. Lorsque la taille du segment est doublée à 256 Mo, comme dans le profil du haut, une augmentation du temps de travail utile est constatée entre les opérations de récupération de place. Ces opérations ne sont plus que trois, mais leur durée a augmenté aussi. Dans le troisième profil, la taille du segment Java est réduite à 64 Mo et on constate l'effet inverse. Avec un segment plus petit, l'intervalle entre deux opérations de récupération de place est plus court et ces opérations sont elles-mêmes plus courtes. Dans les trois cas, le temps total consacré à la récupération de place est approximativement égal à 15 % du temps total d'exécution de l'essai. Ce fait illustre un concept important du segment Java et de sa relation avec l'utilisation des objets. La récupération de place dans les applications Java engendre toujours un coût.
Exécutez une série de tests qui font varier les réglages. Par exemple, faites des essais avec 128 Mo, 192 Mo, 256 Mo et 320 Mo. Lors de chaque essai, surveillez la quantité totale de mémoire utilisée. Si vous augmentez la taille du segment dans des proportions trop importantes, il est possible que vous observiez un début de pagination mémoire. (Utilisez la commande vmstat ou l'Analyseur de performances de Windows NT/2000 pour identifier les phénomènes de pagination.) En cas de pagination, réduisez la taille du segment Java ou ajoutez de la mémoire au système. Une fois tous les essais terminés, comparez les statistiques suivantes :
Si le pourcentage de segment libre atteint 85 % ou plus, pensez à réduire les valeurs de la taille maximale du segment car le serveur d'applications et l'application n'utilisent pas la mémoire allouée au segment dans sa totalité.
le paramètre tcp_close_wait_interval/tcp_time_wait_interval sous Solaris
le paramètre tcp_fin_wait_2_flush_interval sous Solaris
le paramètre tcp_keepalive_interval sous Solaris
De nombreux autres paramètres TCP existent ; les performances de votre environnement peuvent être affectées si vous les modifiez. Pour plus d'informations sur l'optimisation des réglages de la pile TCP/IP, consultez le site Web Tuning your TCP/IP Stack and More.
Avant la modification des paramètres TCP ci-dessus, le serveur se bloquait au cours de certaines périodes de pointe. La commande netstat a révélé que de nombreuses sockets ouvertes sur le port 80 étaient à l'état CLOSE_WAIT ou FIN_WAIT_2.
Dans les deux topologies, la transmission par référence d'Object Request Broker est sélectionnée et la base de données dorsale se trouve sur la machine qui lui est dédiée.
De même, si l'utilisation du processeur des quatre machines est proche des 100 %, il est judicieux d'ajouter une cinquième machine. Ou, si la boîte du serveur Web n'est pas en cours d'exécution à plein capacité et que le traitement du conteneur Web n'est pas lourd, essayez de libérer les processeurs des quatre machines en les déplaçant vers la topologie B.
La même relation s'applique au nombre de connexions du gestionnaire
de sessions. La valeur du paramètre DB2 MaxAppls doit être au moins égale à celle du
nombre de connexions défini dans le gestionnaire de sessions. Si vous utilisez la même base de données pour le stockage des sessions persistantes
et des données de votre application, la valeur de MaxAppls doit être la somme du
nombre de connexions défini dans le gestionnaire de sessions et du nombre maximal
de connexions défini dans la source de données WebSphere.
MaxAppls = (nombre maxi. de connexions dans la source de données + nombre de connexions dans le gestionnaire de sessions) x nombre de clones
Une fois la valeur de chaque paramètre MaxAppls (celui de la base de données WAS et celui de chaque base de données d'application) calculé, vérifiez que la valeur du paramètre DB2 MaxAgents (nombre maximal d'agents) est égale ou supérieure à la somme de toutes les valeurs MaxAppls.
MaxAgents = somme des paramètres MaxAppls de toutes les bases de données
La présente section traite des facteurs à prendre en compte au moment du choix et de la configuration du matériel sur lequel vous prévoyez d'exécuter les serveurs d'applications.
Quant à la mémoire, prévoyez au moins 512 Mo pour chaque processeur.
Pour plus d'informations relatives à la résolution du nom d'hôte sur l'hôte du client d'administration, reportez-vous au livre blanc WebSphere Application Server Admin Best Practices for Performance and Scalability.
Cette section traite des facteurs à prendre en compte lors de la configuration des systèmes d'exploitation présents dans l'environnement des serveurs.
Remarque : Ces deux paramètres doivent être utilisés conjointement lors du réglage de WebSphere Application Server sur un système d'exploitation Windows NT/2000.
ulimit -n 2000
Pour les grosses machines SMP hébergeant des clones de serveur, utilisez la commande suivante :
ulimit -unlimited
Utilisez la commande ulimit -a pour afficher les valeurs en cours de toutes les limites appliquées aux ressources du système.
ulimit -n 1024
Utilisez la commande ulimit -a pour afficher les valeurs en cours de toutes les limites appliquées aux ressources du système.
Le serveur peut se bloquer lors de certaines périodes de pointe. Si cela se produit, la commande netstat indique que de nombreux sockets ouverts sur le port 80 étaient à l'état CLOSE_WAIT ou FIN_WAIT_2. Des délais allant jusqu'à 4 minutes ont été observés, au cours desquels le serveur n'envoyait aucune réponse. Cependant, le taux d'utilisation des processeurs demeurait élevé, toute leur activité étant concentrée dans les processus système.
ndd -get /dev/tcp tcp_time_wait_interval
ndd -set /dev/tcp tcp_time_wait_interval 60000
Le serveur peut se bloquer lors de certaines périodes de pointe. La commande netstat indique que de nombreuses sockets ouvertes sur le port 80 étaient à l'état CLOSE_WAIT ou FIN_WAIT_2. Des délais allant jusqu'à 4 minutes ont été observés, au cours desquels le serveur n'envoyait aucune réponse. Cependant, le taux d'utilisation des processeurs demeurait élevé, toute leur activité étant concentrée dans les processus système.
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval
ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
ndd -get /dev/tcp tcp_keepalive_interval
ndd -set /dev/tcp tcp_keepalive_interval 300000
Des clients ont fait état de leur réussite en modifiant d'autres paramètres TCP sous Solaris, tels que :
tcp_conn_req_max_q
tcp_comm_hash_size
tcp_xmit_hiwat
Bien qu'aucune différence significative n'ait été constatée lors de l'augmentation de la valeur de ces paramètres, ces modifications se révéleront peut-être bénéfiques pour le système.
Définissez-le via l'entrée /etc/system :
set semsys:seminfo_semume = 1024
Définissez-le via l'entrée /etc/system :
semsys:seminfo_semopm = 200
La modification de certains paramètres du système HP-UX 11 permet d'obtenir une amélioration significative des performances de WebSphere Application Server.
chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java
Le résultat de cette commande indique les caractéristiques actuelles de l'exécutable du processus en termes de système d'exploitation.
Pour plus de détails sur cette modification, consultez la page Web suivante sur le site de Hewlett Packard.
connect requests dropped due to full queue (demandes de connexion rejetées en raison de la saturation de la file d'attente).
ndd -set /dev/tcp tcp_conn_request_max 1024
Pour plus de détails sur cette modification, reportez-vous à la page Web de Hewlett Packard .
| Paramètre du noyau | Réglage de WebSphere Application Server | Réglage de DB2 | Réglage d'Oracle |
| maxdsiz | Non réglé | Non réglé | Non réglé |
| maxdsiz_64b | Non réglé | Non réglé | Non réglé |
| maxuprc | 512 | ||
| maxfiles | 2 048 | ||
| maxfiles_lim | 2 048 | ||
| nkthreads | 10 000 | ||
| max_thread_proc | 2 048 | ||
| nproc | 1 028 | ||
| nflocks | 8 192 | ||
| ninode | 2 048 | ||
| nfile | 8 192 | ||
| msgseg | 32 767 | ||
| msgmnb | 65 535 | ||
| msgmax | 65 535 | ||
| msgtql | 1 024 | ||
| msgmap | 258 | ||
| msgmni | 256 | ||
| msgssz | 16 | ||
| semmni | 512 | 70 | |
| semmap | 514 | ||
| semmns | 1 024 | 200 | |
| semmnu | 1 024 | ||
| shmmax | 966 367 642 | 1 Go | |
| shmmseg | 16 | 10 | |
| shmmni | 300 | 100 |
Pour obtenir plus d'informations sur les paramètres du noyau HP-UX, reportez-vous à page Web de Hewlett Packard suivante.
Le produit WebSphere Application Server met à votre disposition des modules d'extension pour plusieurs marques et versions de serveurs Web. A chaque combinaison de serveur Web et de système d'exploitation correspondent des paramètres de configuration spécifiques qui affectent les performances de l'application.
Cette section traite des différents réglages d'optimisation des serveurs Web.
IHS est un serveur multiprocessus à unité d'exécution unique. Pour obtenir plus d'informations, reportez-vous à cette page page Web relative au réglage d'IBM HTTP Server
La configuration par défaut du serveur Web iPlanet Enterprise Edition fournit un serveur monoprocessus, à unités d'exécution multiples.
Pour savoir si le serveur Web est dans cette situation, consultez ses statistiques perfdump. Examinez les données suivantes :
Remarque : Il peut être nécessaire de vérifier les droits d'accès de sePlugin :
Remédiez partiellement à cette situation en utilisant le paramètre ListenBackLog pour augmenter le nombre de demandes qu'IIS conserve dans sa file d'attente.
MaxPoolThreads, PoolThreadLimit
Il est facile de configurer IBM HTTP Server. Le plus souvent, ses réglages par défaut sont acceptables.
Affichage de l'utilisation de l'unité d'exécution : Il existe deux moyens de trouver le nombre d'unités d'exécution utilisées par en charge :
Pour ce faire, suivez la procédure ci-après.
Chaque processus WebSphere Application Server comporte plusieurs paramètres ayant un impact sur les performances de l'application. Chaque serveur d'applications du produit WebSphere Application Server comporte un conteneur d'EJB et un conteneur Web.
Utilisez la console d'administration WebSphere Application Server afin de configurer et de régler les applications, les conteneurs Web, les conteneurs d'EJB, les serveurs d'applications et les noeuds du domaine d'administration.
Comment voir l'utilisation du paramètre : Sous UNIX, utilisez la commande ps -efl pour voir la priorité du processus en cours.
Pour aiguiller les demandes de servlet entre le serveur Web et les différents conteneurs Web, le produit établit une file de transport entre le module d'extension (plug-in) du serveur Web et chaque conteneur Web.
Resource Analyzer affiche un paramètre appelé Taux d'utilisation maximale qui détermine la durée pendant laquelle les unités d'exécution configurées sont utilisées. Si cette valeur comporte toujours deux chiffres, alors le conteneur Web peut se transformer en goulet d'étranglement et le nombre d'unités d'exécution doit être augmenté.
Une cache de la taille demandée est créée pour chaque unité d'exécution. Le nombre d'unités d'exécution est déterminé par le paramètre de taille maximale de l'unité d'exécution du conteneur Web.
Remarque : Pour une cache de taille supérieure, vous devez disposer de plus d'espace dans le segment Java. Il peut donc être nécessaire d'augmenter la taille maximale du segment Java. Par exemple, si pour chaque entrée de cache, deux Ko sont nécessaires, la taille maximale de l'unité d'exécution est définie à 25 et la taille de la cache des appels d'URL à 100. Dans ce cas, 5 Mo de segment Java sont nécessaires.
Pour visualiser les données de performance des beans, utilisez l'Analyseur de ressources (Resource Analyzer).
Les informations de sécurité relatives aux beans, aux droits d'accès et aux justificatifs sont mémorisées en cache. A l'expiration du délai défini, toutes les informations stockées en cache perdent leur validité. Dès lors, toute demande portant sur l'une de ces informations nécessite une nouvelle consultation de la base de données. L'obtention de ces informations sollicite parfois un mécanisme d'authentification natif du système d'exploitation local (registre d'utilisateurs) ou s'appuyant sur un service d'annuaires LDAP. Quel que soit le mécanisme utilisé, cette authentification est relativement coûteuse en termes de performances.
Testez plusieurs délais afin de trouver le meilleur compromis pour l'application compte tenu des conditions d'utilisation et des besoins de sécurité de votre site.
Les propriétés système suivantes déterminent la taille initiale des tables de hachage principales et secondaires de la cache, qui influe sur la fréquence de nouveaux hachages ainsi que sur la distribution des algorithmes de hachage. Plus le nombre de valeurs de hachage est élevé, moins le risque de collision de hachage est élevé. De plus l'extraction est plus lente. Si plusieurs entrées composent une table de hachage de la cache, la création de la table avec une plus grande capacité permet l'insertion d'entrées de manière plus efficace au lieu de laisser le hachage automatique déterminer la croissance de la table. Une nouvelle procédure de hachage provoque le déplacement de chaque entrée dès que cette opération est effectuée.
La fonction SAS (Secure Association Service) établit une connexion SSL uniquement si la connexion sort de la JVM (vers une autre JVM). C'est pourquoi, si tous les beans sont localisés dans une même JVM, il ne devrait pas y avoir de baisse de performances.
Pour définir ces paramètres, sélectionnez l'onglet Services puis Edition des propriétés pour Object Request Broker, pour le serveur par défaut ou pour tout serveur d'applications supplémentaire configuré dans le domaine d'administration.
AVERTISSEMENT : Une transmission par référence peut être dangereuse et aboutir à des résultats inattendus. Ceci est possible dans le cas où une référence d'objet est modifiée par la méthode éloignée.
Si le serveur d'applications attend une charge de travail importante pour les demandes de bean enterprise, la configuration de l'ORB peut poser des problèmes. Prenez en compte les propriétés suivantes :
Une quantité inférieure de mémoire est nécessaire lors de l'utilisation de JNIReaders car un ensemble fixe d'unités d'exécution doit être créé. Vous gagnez du temps car les créations d'unité d'exécution sont effectuées une seule fois lors de l'initialisation et les unités d'exécution ne sont jamais supprimées. L'unité d'exécution JNIReader est une implémentation C natif et doit être plus rapide que l'unité d'exécution du programme de lecture par défaut.
AVERTISSEMENT : Assurez-vous que l'implémentation de la bibliothèque JNI de JNIReader se trouve dans le répertoire bin de WebSphere Application Server. Pour la plateforme Intel, la bibliothèque est Selector.dll et pour UNIX, il s'agit de libSelector.a ou de libSelector.so. Pour Unix, si le préfixe "lib" manque, le fichier doit être renommé.
Optimisation des réglages de la JVM
Plusieurs paramètres de configuration de la JVM peuvent avoir un impact sur les performances des serveurs d'applications WebSphere (qui sont principalement des applications Java) ainsi que sur les performances de vos applications.
En général, l'augmentation de la taille du segment Java améliore le débit, jusqu'à ce que le segment ne puisse plus résider en mémoire physique. Si cette limite est franchie, le segment "déborde" sur le disque et la permutation qui en résulte réduit considérablement les performances de Java. Par conséquent, il est important d'attribuer une valeur suffisamment basse à la taille maximale du segment pour que ce dernier puisse tenir en entier dans la mémoire physique.
L'utilisation de la mémoire physique doit être partagée entre la JVM et les autres applications (par exemple, la base de données). Pour une question de sécurité, il est préférable d'utiliser un segment de taille moindre (par exemple 64 Mo sur les machines ayant une capacité limitée).
Vous pouvez choisir une taille maximale de 128 Mo sur une machine de faible capacité (inférieure à 1 Go de mémoire physique), de 256 Mo sur une machine de capacité moyenne (2 Go) et 512 Mo pour les systèmes plus puissants. Le point de départ dépend de l'application.
Si vous effectuez des tests de performances et que les résultats de ces tests doivent être hautement reproductibles, attribuez la même valeur à la taille initiale et maximale. Ainsi, la taille du segment est immuable et vous pouvez plus facilement comparer les résultats des différents tests. Sur des systèmes de production pour lesquels il est difficile de déterminer précisément la taille de la partie active des applications Java, vous pouvez commencer par un paramètre initial quatre fois plus petit que la valeur maximale. La JVM essaiera ensuite d'adapter la taille du segment à la partie active de l'application Java.
Pour définir les paramètres de la JVM, utilisez la propriété de ligne de commande du serveur par défaut ou de tout autre serveur d'applications que vous configurez dans le domaine d'administration.
WebSphere Application Server s'intègre étroitement avec plusieurs marques et versions de produits base de données. Pour plus d'informations sur les produits de base de données supportés, consultez le site Web des éléments prérequis pour le produit à l'adresse www.ibm.com/software/webservers/appserv/library.html. WebSphere Application Server utilise la base de données comme lieu de stockage persistant, tant pour les données d'administration que pour l'état des sessions et les données des beans enterprise de l'application.
Si l'application utilise le support de session WebSphere Application Server, la mise en pool des connexions à la base de données JDBC ou des beans enterprise, faites attention à la manière dont vous configurez ces ressources et leurs paramètres de base de données dans le domaine d'administration. Lors de l'installation de WebSphere Application Server, une base de données nommée WASnn est créée dans laquelle n correspond à l'identificateur de la version. Il est également possible d'utiliser un nom différent. Dans ce document, on suppose que WAS40 est utilisé.
Pour l'évolutivité, il est possible de créer la base de données sur une machine séparée, en particulier si vous utilisez un environnement en cluster. Cela concerne la base de données WebSphere Application Server, toute base de données d'application ainsi que la base de données des sessions WebSphere Application Server (si vous utilisez une session persistante).
Si vous utilisez des clones, un pool de sources de données existe pour chaque clone. Ceci est important lors de la configuration du nombre maximal de connexions au serveur de base de données.
Resource Analyzer permet de trouver le nombre optimal de pool de connexions pour lesquels il est possible de réduire ces valeurs. Si la valeur de Taux d'utilisation est toujours faible, pensez à réduire le nombre de connexions dans le pool.
Sur les plates-formes UNIX, un processus DB2 séparé est créé pour chaque connexion. Cela peut vite dégrader les performances et conduire à des erreurs sur les systèmes ayant une faible capacité mémoire.
Pour chaque transaction d'EJB entity, une connexion supplémentaire à la base de données est nécessaire pour la gestion de la transaction. N'oubliez pas de prendre cet élément en compte lors du calcul du nombre de connexions à la base de données. Un blocage peut se produire si l'application nécessite plusieurs connexions simultanées par unité d'exécution et que la taille du pool de connexions à la base de données n'est pas assez importante pour le nombre d'unités d'exécution. Supposez que chacune des unités d'exécution d'application nécessite deux connexions simultanées à la base de données et que le nombre d'unités d'exécution soit égal à la taille maximale du pool de connexions. Un blocage peut se produire lorsque les deux conditions suivantes sont vérifiées :
Pour empêcher le blocage, la valeur définie pour la taille du pool de connexions à la base de données doit comporter au moins un élément de plus, de telle sorte qu'au moins l'une des unités d'exécution en attente puisse mener à terme sa deuxième connexion à la base de données, libérant ainsi des connexions à la base de données.
Pour éviter un blocage, codez l'application à utiliser, au moins une connexion par unité d'exécution. Si l'application est codée de telle sorte qu'elle demande des connexions à la base de données concurrente de type C par unité d'exécution, le pool de connexions à la base de données doit prendre en charge le nombre suivant de connexions, où T correspond au nombre maximal d'unités d'exécution.
T * (C - 1) + 1
Les paramètres du pool de connexions sont directement liés au nombre de connexions pouvant être prises en charge par le serveur de bases de données. Si vous augmentez le nombre maximal de connexions dans le pool et que vous n'augmentez pas les paramètres correspondants dans la base de données, l'application échoue et des exceptions SQL s'affichent dans le fichier stderr.log.
Remarque : Les instructions préparées sont optimisées pour le traitement des instructions SQL paramétriques qui bénéficient de la précompilation. Si le pilote JDBC spécifié dans la source de données accepte la précompilation, les instructions préparées seront envoyées à la base de données en vue d'y être précompilées. Certains pilotes n'admettent pas la précompilation. Dans ce cas, les instructions préparées ne sont envoyées à la base de données qu'au moment d'être exécutées.
La source de données WebSphere Application Server gère un pool de connexions à la base de données ainsi qu'une cache associée dans laquelle sont conservées les instructions préparées. Les instructions préparées sont mises en cache avec une balise identifiant chaque connexion qui les exécute. La relation entre les instructions SQL utilisées, la cache des instructions préparées, une source de données et une base de données constituent des éléments utiles à réviser. Supposons qu'une application utilise cinq instructions SQL : deux instructions select, une instruction delete, une instruction insert et une instruction update.
La source de données ci-dessus est configurée avec un maximum de trois connexions simultanées à la base de données. Les connexions ont déjà été créées et de nombreuses instructions SQL ont été exécutées. La cache des instructions préparées a été configurée pour contenir 10 instructions. Trois instructions préparées sont stockées en cache pour les connexions 1 et 2. Il y en a quatre pour la connexion 3. Comme les instructions sont compilées en instructions préparées à mesure qu'elles sont utilisées, la contenu de la cache reflète la manière dont l'application utilise la base de données. La cache des instructions préparées s'appuie sur une file d'attente de type FIFO (premier entré, premier sorti). Un objet instruction préparée représentant une instructions SQL donnée peut apparaître en plusieurs endroits de la cache. En particulier, il peut apparaître pour chaque connexion du pool de connexions. Par exemple, les instructions 1 et 2 sont reproduites en trois endroits différents de la cache, soit une fois par connexion. L'instruction 3 n'apparaît pas pour la connexion 3 et les instructions 4 et 5 apparaissent uniquement pour la connexion 3. C'est pourquoi, l'exécution des instructions 4 et 5 sur les connexions 1 et 2 peut prendre un peu plus de temps car il faut qu'elles soient recompilées pour ces connexions. Dans cet exemple, la meilleure solution est de porter à 15 la taille de la cache des instructions préparées, ce qui laisserait la place à un exemplaire des cinq instructions pour chacune des trois connexions.
Resource Analyzer peut vous aider à régler ces paramètres afin de réduire le nombre d'éléments ignorés dans la cache. Utilisez une charge de travail standard qui représente un nombre classique de demandes client entrantes, utilisez un nombre fixe d'itérations ainsi qu'un ensemble standard de paramètres de configuration.
Pour utiliser Resource Analyzer, suivez les instructions ci-après.
La meilleure valeur pour Source de données > Mise en pool des connexions > Taille de la cache d'instructions est le paramètre permettant d'extraire une valeur zéro ou la valeur inférieure pour Elimination de la cache des instructions préparées. De cette façon, vous indiquez le nombre le plus efficace pour une charge de travail classique.
Autres paramètres JDBC
En plus de la définition de la taille de la cache des instructions préparées, vous pouvez définir d'autres propriétés spécifiques aux pilotes JDBC. Par
exemple, si vous utilisez une base de données Oracle, vous pouvez augmenter le nombre de lignes à lire lors de l'extraction
d'ensembles de résultats en insérant l'instruction suivante :
name="defaultRowPrefetch", value="25"
Entrez ces types de propriétés personnalisées dans l'onglet Généralités pour la base de données.
Pour attribuer la valeur n à BUFFPAGE, émettez la commande DB2 update db cfg for x using BUFFPAGE n et assurez que NPAGES a la valeur -1 de la manière suivante :
db2 <-- passez en mode de commande DB2, sinon la commande "select" suivante ne fonctionnera pas
connect to x <-- (où x est le nom de la base de données DB2 particulière)
select * from syscat.bufferpools
(et notez le nom par défaut, par exemple : IBMDEFAULTBP)
(si la valeur de NPAGES est déjà -1, vous n'avez pas besoin d'émettre la commande suivante)
alter bufferpool IBMDEFAULTBP size -1
(entrez à nouveau l'instruction "select" et NPAGES doit être égal à -1)
Le niveau 9 entraîne DB2 à utiliser beaucoup de son temps et la totalité des statistiques dont il dispose pour optimiser le plan d'accès.
Pour plus d'informations, reportez-vous à la documentation DB2 ainsi qu'au site Web IBM DB2.
Afin de vérifier si la mise à jour des statistiques a été effectuée, émettez la commande suivante sur DB2 CLP :
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
Si aucune mise à jour de statistiques n'a été effectuée, la valeur -1 est attribuée à nleaf et à nlevels et aucune valeur n'est attribuée à stats_time "-".
Si une mise à jour des statistiques a déjà été effectuée, la date et l'heure d'exécution en temps réel de la mise à jour des statistiques sera affichée sous stats_time. Si vous estimez que la mise à jour de statistiques précédente est trop vieille, effectuez à nouveau cette opération.
Le nouveau paramètre prend effet immédiatement.
Ci-dessous se trouvent différents paramètres liés à DB2 MinCommit :
Pour obtenir plus d'informations sur la définition des paramètres de gestion de session, reportez-vous à l'article 4.4.1.1 de l'InfoCenter Modèle et environnement de programmation de sessions.
Lors de l'activation de la trace dans le composant cmm, vous constatez l'utilisation de ce paramètre.
Vous devez utiliser la valeur 1 si vous voulez traiter les messages en série. Dans ce cas, seule une instance de bean de message est utilisée pour le traitement des messages les uns après les autres.
Avec la valeur 20, vous obtiendrez le meilleur débit. Le débit ne sera pas amélioré si vous utilisez une valeur supérieure. En fonction du type de message, du montant de travail et des ressources disponibles, utilisez une valeur comprise entre 10 et 20 pour obtenir le débit de messages maximal.
L'augmentation du débit de messages dépend de plusieurs facteurs, tels que les ressources système et la configuration du programme d'écoute. Le nombre et la puissance des processeurs constituent les ressources système. La configuration du programme fait référence au nombre de sessions utilisées ainsi qu'aux interactions JMS. Dans les interactions JMS, se trouve le conflit de partage de l'accès aux ressources sous-jacentes du gestionnaire MQ Server.
Effectuez les opérations suivantes :
Dans le menu Démarrer, sélectionnez Programmes > Outils d'administration > Analyseur de performances