Optimisation de Liberty
Vous pouvez optimiser les paramètres et les attributs de Liberty.
Pourquoi et quand exécuter cette tâche
Procédure
- Optimisez la machine virtuelle Java. L'optimisation de la machine virtuelle Java est l'une des étapes de configuration les plus importantes, que vous configuriez un environnement de développement ou un environnement de production. Lorsque vous optimisez la machine virtuelle Java pour Liberty, utilisez le fichier jvm.options dans le répertoire ${server.config.dir}. Vous pouvez spécifier chaque argument de machine virtuelle Java que vous voulez utiliser, en indiquant une option par ligne. Pour plus d'informations, voir Personnalisation de l'environnement Liberty. Voici un exemple de fichier jvm.options :
-Xms50m -Xmx256m
Dans le cas d'un environnement de développement, il peut être intéressant d'accélérer le démarrage du serveur ; par conséquent, envisagez d'associer la taille de segment minimale à une valeur faible, et la taille de segment maximale à la valeur requise pour votre application, quelle qu'elle soit. Dans le cas d'un environnement de production, l'association de la taille de segment minimale et de la taille de segment maximale à la même valeur peut permettre d'obtenir de meilleures performances, car vous évitez l'extension et la contraction du segment de mémoire.
- Optimisez les services de canal de transport. Les services de canal de transport gèrent les connexions client, le traitement des E-S pour HTTP, les pools d'unités d'exécution et les pools de connexions. Pour les applications Liberty, les attributs ci-dessous sont disponibles pour différents éléments pouvant être utilisés afin d'améliorer les performances d'exécution, l'évolutivité, ou les deux.
- maxKeepAliveRequests de httpOptions
- Cette option spécifie le nombre maximal de demandes persistantes qui sont admises sur une connexion HTTP unique si les connexions persistantes sont activées. La valeur -1 signifie que le nombre est illimité. Cette option prend en charge les applications et les connexions SSL à temps d'attente faible ou à haut débit dans des cas où l'établissement d'une nouvelle connexion peut s'avérer coûteuse. Exemple de codage de cette option dans le fichier server.xml :
<httpOptions maxKeepAliveRequests="-1" />
- maxPoolSize de connectionManager
- Cette option spécifie le nombre maximal de connexions physiques pour le pool de connexions. La valeur par défaut est 50.
Dans ce cas, le paramètre optimal dépend des caractéristiques de l'application.
Pour une application dans laquelle chaque unité d'exécution obtient une connexion à la base de données, vous pouvez commencer par le mappage 1:1 à l'attribut coreThreads. Exemple de codage de cette option dans le fichier server.xml :
<connectionManager ... maxPoolSize="40" />
- purgePolicy de connectionManager
- Cette option spécifie les connexions à détruire lorsqu'une connexion périmée est détectée dans un pool. Par défaut, l'intégralité du pool est détruit. Il peut être plus judicieux de ne purger que la connexion défaillante. Exemple de codage de cette option dans le fichier server.xml :
<connectionManager ... purgePolicy="FailingConnectionOnly" />
- numConnectionsPerThreadLocal de connectionManager
- Cette option spécifie le nombre de connexions de base de données à mettre en cache pour chaque unité d'exécution de l'exécuteur. Ce paramètre peut améliorer considérablement le comportement sur les grandes machines à plusieurs coeurs (huit ou plus) en réservant le nombre spécifié de connexions de base de données pour chaque unité d'exécution.
- L'utilisation d'une mémoire locale d'unité d'exécution pour les connexions peut améliorer les performances pour les applications qui se trouvent sur des systèmes multiprocessus. Si vous associez numConnectionsPerThreadLocal à 1 ou à une valeur plus élevée, ces connexions par unité d'exécution sont stockées dans une mémoire locale d'unité d'exécution.
Lorsque vous utilisez numConnectionsPerThreadLocal, envisagez les
deux autres valeurs :
- Le nombre d'unités d'exécution d'application
- Le nombre de connexions maximale dans le pool de connexions
<connectionManager ... numConnectionsPerThreadLocal="1" />
- statementCacheSize de dataSource
- Cette option spécifie le nombre maximal d'instructions préparées mises en cache par connexion. Pour la définir, procédez comme suit :
- Révisez dans le code d'application (ou une trace SQL générée à partir de la base de données ou du pilote de base de données) toutes les instructions préparées uniques.
- Vérifiez que la taille du cache est supérieure au nombre d'instructions.
<dataSource ... statementCacheSize="60" >
- isolationLevel de dataSource
- Le niveau d'isolement de la source de données spécifie le degré d'accès concurrent et d'intégrité des données, qui à son tour contrôle le niveau de verrouillage de la base de données.
Il existe quatre options, indiquées ci-dessous en fonction de leur résultat : du meilleur (intégrité moindre) au pire (meilleure intégrité).
- TRANSACTION_READ_UNCOMMITTED
- Des lectures de pages modifiées, des lectures non reproductibles et des lectures fantômes peuvent survenir.
- TRANSACTION_READ_COMMITTED
- Les lectures de pages modifiées sont interdites ; les lectures non reproductibles et les lectures fantômes sont autorisées.
- TRANSACTION_REPEATABLE_READ
- Les lectures de pages modifiées et les lectures non reproductibles sont interdites ; les lectures fantômes sont autorisées.
- TRANSACTION_SERIALIZABLE
- Les lectures de pages modifiées, les lectures non reproductibles et les lectures fantômes sont évitées.
<dataSource ... isolationLevel="TRANSACTION_READ_COMMITTED">
- Optimisez le programme d'exécution par défaut.
Le programme d'exécution par défaut de Liberty se règle automatiquement et s'adapte à la charge de travail en cours en ajoutant ou retirant des unités d'exécution de manière dynamique. Pour la plupart des charges de travail, le programme d'exécution ne requiert aucun réglage et il est conseillé de ne pas modifier les paramètres à moins de rencontrer des problèmes spécifiques lors de la création d'unités d'exécution.
Si nécessaire, vous pouvez configurer les paramètres coreThreads et maxThreads de l'élément executor dans le fichier server.xml pour définir des limites inférieure et supérieure pour le code de réglage automatique de Liberty. Le paramètre coreThreads n'est généralement pas nécessaire car le programme d'exécution contient du code anti-interblocage agressif qui ajoute des unités d'exécutions pour lui permettre de sortir de scénarios d'interblocage. Il arrive parfois que le code anti-interblocage ajoute plus d'unités d'exécution que nécessaire. Dans ce cas, vous pouvez utiliser le paramètre maxThreads de l'élément executor pour plafonner le nombre d'unités d'exécution que le programme d'exécution est autorisé à créer.
- Diminuez le temps de réponse des servlets.
Pour réduire le temps de réponse des servlets, ajoutez l'attribut suivant au fichier server.xml :
<webContainer skipMetaInfResourcesProcessing="true"/>
- Réduisez le temps UC des serveurs inactifs.
Pour réduire le temps UC d'un serveur inactif, ajoutez les attributs suivants au fichier server.xml :
<applicationMonitor dropinsEnabled="false" updateTrigger="disabled"/> <config updateTrigger="disabled"/>
Lorsque les attributs sont ajoutés, votre serveur ne surveille plus les mises à jour de l'application ni configuration.
- Réglage du temps de démarrage.
- CDI 1.2
- Par défaut, la fonction CDI 1.2 analyse toutes les archives d'application. La fonction CDI 1.2
peut augmenter de manière significative le temps de démarrage et avoir l'impact le plus large
sur les applications de grande taille. L'analyse d'archives implicite pour les annotations
peut être désactivée en définissant la valeur de enableImplicitBeanArchives
sur false. Ce paramètre ignore l'analyse des archives sauf si elles contiennent
un fichier beans.xml.
<cdi12 enableImplicitBeanArchives="false"/>
Remarque : La fonction cdi-1.2 peut être incluse même si elle ne figure pas à la section <features> de votre fichier server.xml parce que d'autres fonctions, telles que webProfile-7.0 et javaee-7.0, incluent la fonction cdi-1.2. Recherchez dans le fichier messages.log "The server installed the following features:" (le serveur a installé les fonctions suivantes) afin de voir si cdi-1.2 a été installé.
Sous-rubriques
- Optimisation de Liberty pour les applications sécurisées
Vous pouvez optimiser Liberty afin d'améliorer les performances pour les applications sécurisées. - Optimisation des référentiels LDAP fédérés dans Liberty
Vous pouvez améliorer les performances des référentiels fédérés LDAP en surveillant et ajustant les éléments de pool de contexte et cache dans le fichier server.xml.


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