Mise au point de serveurs d'applications
Le produit contient des 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.
Pourquoi et quand exécuter cette tâche
Ce groupe de composants reliés entre eux est appelé réseau de files d'attente. Ce réseau de files d'attente aide à optimiser le débit tout en préservant la stabilité globale du système.
Les différentes tâches de mise au point susceptibles d'améliorer les performances de votre serveur d'applications sont décrites ci-après. Vous pouvez choisir d'implémenter n'importe quel paramètre du serveur d'applications. Ces étapes peuvent être effectuées dans n'importe quel ordre.
Procédure
- Exécutez le script applyPerfTuningTemplate.py pour commencer à améliorer les performances d'un serveur d'applications.
Vous pouvez utiliser le script de réglage basé sur python, applyPerfTuningTemplate.py, avec l'un de ses fichiers modèle pour appliquer les paramètres de réglage de performances recommandés. Le script et ces fichiers modèle sont situés dans le répertoire WAS_HOME/bin.
- Optimisez l'ORB. Un courtier ORB (Object Request Broker) gère l'interaction entre les clients et les serveurs, à
l'aide du protocole IIOP (Internet InterORB Protocol).
Il prend en charge les demandes client et les
réponses reçues des serveurs dans un environnement réseau réparti. Vous pouvez utiliser les paramètres suivants pour optimiser le conteneur ORB :
- Définissez Transmission par référence (com.ibm.CORBA.iiop.noLocalCopies) comme indiqué dans les informations sur les paramètres du service Object Request Broker.
Définissez la Taille minimale de la mémoire cache des connexions (com.ibm.CORBA.MaxOpenConnections) comme indiqué dans les informations sur les paramètres du service Object Request Broker.
Définissez la taille maximale comme décrit dans la rubrique sur les paramètres du pool d'unités d'exécution.
Définissez com.ibm.CORBA.ServerSocketQueueDepth comme décrit dans les informations sur les propriétés personnalisées Object Request Broker.
- Définissez com.ibm.CORBA.FragmentSize comme décrit dans les informations sur les propriétés personnalisées Object Request Broker.
Voir les instructions de réglage d'Object Request Broker pour des conseils sur l'utilisation de ces paramètres pour optimiser l'ORB.
- Optimisez les définitions de l'analyseur XML.
- Description : Facilite le démarrage du serveur en ajoutant les définitions d'analyseurs XML aux fichiers jaxp.properties et xerces.properties dans le répertoire ${app_server_root}/jre/lib. La valeur XMLParserConfiguration est susceptible d'être modifiée pour les versions ultérieures de Xerces.
- Comment voir et définir : Insérez les lignes suivantes dans les deux fichiers :
Vous pouvez également consulter les fichiers jre/lib/jaxp.properties et jre/lib/xerces.properties fournis avec l'installation de JDK. Ces exemples de fichiers contiennent toujours les paramètres recommandés.javax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl javax.xml.parsers.DocumentBuildFactory=org.apache.xerces.jaxp. DocumentBuilderFactoryImpl org.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers. XIncludeAwareParserConfiguration
- Valeur par défaut : Aucune
- Valeur recommandée : Aucune
- Optimisez le service de cache dynamique.
L'utilisation du service de cache dynamique peut améliorer les performances. Voir la rubrique sur l'utilisation du serveur cache dynamique pour améliorer les performances pour plus d'informations sur l'utilisation du service de cache dynamique et sur l'incidence sur les performances du serveur d'applications.
Optimisez le conteneur Web. Le conteneur Web du produit gère toutes les demandes HTTP adressées aux servlets, JavaServer Pages et services Web. Les demandes transitent via une chaîne de transport vers le conteneur Web. La chaîne de transport définit des paramètres d'optimisation important de performances pour le conteneur Web. Il s'agit d'une chaîne de transport pour chaque port TCP sur lequel le produit attend les requêtes HTTP. Par exemple, le port HTTP 9080 par défaut est défini dans la chaîne de canal des communications entrantes du conteneur Web. Utilisez les paramètres suivants pour optimiser le conteneur Web :
- Les demandes HTTP sont traitées par un pool d'unités d'exécution serveur. La taille minimale et la taille maximale
de pool d'unités d'exécution du conteneur Web peuvent être configurées pour des performances optimales. En général, de cinq à dix unités d'exécution par unité centrale serveur fournissent les meilleures performances. Le nombre d'unités d'exécution configuré ne représente pas le nombre de demandes concurrentes que peut traiter le produit. Les demandes sont mises en file d'attente dans la chaîne de transport quand toutes les unités d'exécution sont occupées. Pour indiquer les paramètres de pool d'unités d'exécution :
- Cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere >nom_serveur Paramètres du conteneur Web > Conteneur Web > Chaînes de transport du conteneur Web.
- Sélectionnez la chaîne entrante normale destinée à servir des demandes. Il s'agit généralement de la chaîne WCInboundDefault, qui écoute sur le port 9080.
- Cliquez sur Canal des communications entrantes TCP (TCP_2).
- Définissez Pools d'unités d'exécution sous Articles liés.
- Sélectionnez Conteneur Web.
- Entrez des valeurs pour Taille minimale et Taille maximale.
- Le protocole HTTP 1.1 offre une fonction keep-alive ce qui permet à la connexion TCP entre clients HTTP et le serveur de rester ouverte entre les requêtes. Par défaut, le produit ferme une connexion client donnée après un certain nombre de demandes ou à l'expiration d'un délai. Une fois fermée, une connexion est recréée si le client émet une nouvelle demande. La fermeture prématurée de connexions peut réduire les performances. Entrez le nombre maximal de demandes persistantes ("keep-alive") correspondant au nombre de demandes acceptées pour une connexion HTTP. Entrez une valeur pour les délais persistants, ce qui permet d'indiquer le nombre de secondes pendant lequel le transport HTTP autorise l'inactivité d'une connexion entre deux demandes. Pour indiquer les valeurs de Nombre maximal de demandes persistantes et de Délai persistant :
- Cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere >nom_serveur. Puis, dans la section Paramètres du conteneur, cliquez sur Conteneur Web > Chaînes de transport du conteneur Web.
- Sélectionnez la chaîne entrante normale destinée à servir des demandes. Il s'agit généralement de la chaîne WCInboundDefault, qui écoute sur le port 9080.
- Cliquez sur Canal des communications entrantes HTTP (HTTP_2).
- Complétez les zones Nombre maximal de demandes persistantes et Délai persistant.
- Les demandes HTTP sont traitées par un pool d'unités d'exécution serveur. La taille minimale et la taille maximale
de pool d'unités d'exécution du conteneur Web peuvent être configurées pour des performances optimales. En général, de cinq à dix unités d'exécution par unité centrale serveur fournissent les meilleures performances. Le nombre d'unités d'exécution configuré ne représente pas le nombre de demandes concurrentes que peut traiter le produit. Les demandes sont mises en file d'attente dans la chaîne de transport quand toutes les unités d'exécution sont occupées. Pour indiquer les paramètres de pool d'unités d'exécution :
- Optimisez le conteneur EJB. Un conteneur d'EJB (Enterprise JavaBeans) est créé
automatiquement en même temps que le serveur d'applications. Une fois que le conteneur d'EJB a été déployé,
vous pouvez utiliser les paramètres d'optimisation suivants qui permettent d'améliorer les performances.
- Définissez l'intervalle de nettoyage et la taille du cache. Pour plus d'informations, voir la rubrique sur les paramètres du cache d'EJB.
- Répartissez les beans enterprise CMP en plusieurs modules de beans enterprise. Pour plus d'informations, voir la rubrique sur l'assemblage des modules d'EJB.
Pour plus d'informations, voir la rubrique sur la mise en file d'attente des appels de méthode EJB.
- Optimisez la gestion des sessions.
Les paramètres indiqués par défaut pour la gestion des sessions ont été définis pour des performances optimales.
- Optimisez les sources de données et les pools de connexions associés. Une source de
données permet d'accéder aux données de la base de données ; elle est associée à un
pool de connexions de cette base de données.
- Consultez la rubrique sur le regroupement de connexions pour comprendre comment le nombre de connexions physiques d'un pool de connexions est susceptible de modifier les performances.
Utilisez la rubrique sur les paramètres de réglage de l'accès aux données comme référence pour les propriétés de la source de données et du pool de connexions qui affectent le plus les performances.
- Optimisez le cache d'appel URL.
Chaque JavaServer Page est une URL unique. Si vous possédez plus de 50 URL uniques actives, augmentez la valeur spécifiée pour la propriété personnalisée JVM invocationCacheSize. Cette propriété contrôle la taille du cache d'appel.
Changez la fréquence à laquelle le service de journal de reprise tente de compresser les flots de journalisation que les composants d'application utilisent.
La propriété personnalisée du Service de transaction RLS_LOGSTREAM_COMPRESS_INTERVAL peut être définie avec une valeur plus grande que la valeur par défaut si le Service de transaction est le seul composant d'application utilisant un flot de journalisation. Si aucun de vos composants n'est configuré pour utiliser un flot de journalisation, vous pouvez définir cette propriété sur 0 (zéro) pour désactiver cette fonction.
Sous-rubriques
Optimisation du serveur d'applications à l'aide des modèles d'optimisation prédéfinis
Vous pouvez utiliser le script de réglage basé sur python, applyPerfTuningTemplate.py, avec l'un de ses fichiers modèle pour appliquer les paramètres de réglage de performances recommandés à votre cluster ou serveur d'applications. Les fichiers modèle basés sur une propriété se trouvent dans le répertoire WAS_HOME\scriptLibraries\perfTuning\V70. Le chemin pour les fichiers de script est le suivant : wsadmin -f <WAS_HOME>\bin\applyPerfTuningTemplate.py.Communication optimisée entre un client de services Web et un conteneur web
Pour de meilleures performances, il existe un chemin de communication optimisée entre une application client de services web et un conteneur web, situés dans le même processus du serveur d'applications. Les demandes émises par le client de services web sont normalement envoyées au conteneur web en passant par une connexion réseau, alors qu'ici, elles sont livrées directement au conteneur web en empruntant un chemin local optimisé. La disponibilité de ce chemin local provient du fait que l'application client de services web et le conteneur web s'exécutent dans le même processus.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_tuneappserv
Nom du fichier : tprf_tuneappserv.html