![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Instruction d'optimisation d'ORB (Object Request Broker)
Utilisez les instructions du présent document chaque fois que l'ORB (Object Request Broker) est utilisé dans une charge de travail.
L'objet ORB est utilisé chaque fois qu'un processus accède à des beans enterprise via une interface éloignée. Si vous constatez que l'utilisation du processeur est particulièrement élevée ou basse, il est possible que l'un des paramètres suivants doivent être redéfini. Examinez ces principaux paramètres d'adaptation pour chaque déploiement d'applications.
Adaptation des paramètres du pool d'unités d'exécution
Taille
Ajustez la taille du pool d'unités d'exécution en fonction de la charge de travail. Evitez les unités d'exécution en suspens car les tâches qu'elles ont à traiter ne sont pas encore prêtes. Dans ce cas, le temps du processeur est utilisé en appelant la méthode Object.wait avec un changement de contexte. Ajustez la taille du pool d'unités d'exécution pour que le délai d'attente des unités d'exécution soit suffisamment court pour leur éviter d'être détruites en raison d'une trop longue inactivité.
La taille du pool d'unités d'exécution varie en fonction de la charge de travail et de votre système. Dans les configurations classiques, les applications ont besoin de 10 unités d'exécution maximum par processeur.
Toutefois, si l'application effectue une requête du système dorsal particulièrement lente (par exemple, une requête vers un système de base de données), une unité d'exécution du serveur est bloquée en attendant la fin du traitement de la requête du système dorsal. Pour le traitement des requêtes du système dorsal, l'utilisation du processeur est relativement faible. Dans ce cas, l'augmentation de la charge n'augmente pas l'utilisation du processeur ou le débit. Les clichés de l'unité d'exécution indiquent que presque toutes les unités d'exécution appellent la ressource du système dorsal. Dans ce cas, vous pouvez envisager d'augmenter le nombre d'unités d'exécution par processeur jusqu'à ce que le débit augmente et que le cliché des unités d'exécution indique que les unités d'exécution se trouvent dans d'autres parties de l'environnement d'exécution que l'appel du système dorsal. Vous devez adapter le nombre d'unités d'exécution uniquement si la ressource du système dorsal est correctement configurée.
Le paramètre Permet d'allouer un nombre d'unités d'exécution dépassant la taille maximale autorisée a également une incidence sur la taille du pool d'unités d'exécution mais vous ne devez pas l'utiliser sauf si le système dorsal s'arrête de manière prolongée et entraîne le blocage de toutes les unités d'exécution en attendant le redémarrage du système dorsal au lieu de traiter d'autres tâches qui n'impliquent pas ce système.
Vous pouvez adapter les paramètres qui définissent la taille du pool d'unités d'exécution dans la console d'administration. Cliquez sur Serveurs > Types de serveurs > Serveurs d'applications > nom_serveur > Services du conteneur > Service ORB > Pool d'unités d'exécution. Vous pouvez adapter le nombre minimal ou maximal d'unités d'exécution.
Délai d'attente du pool d'unités d'exécution
Chaque demande entrante et chaque demande sortante via ORB requiert une unité d'exécution du pool d'unités d'exécution ORB. Dans les situations de forte charge, ou dans celles où les demandes ORB sont fortement imbriquées, il peut arriver que toutes les unités du pool d'unités d'exécution ORB d'une machine virtuelle Java™ soient en train d'essayer d'envoyer des demandes. Pendant le même temps, toutes les unités du pool d'unités d'exécution du service ORB de la machine JVM distante qui traite ces demandes tente, lui-aussi, d'envoyer des demandes. Dans cette situation, les unités du pool ORB ne se libèrent pas, le service ORB n'arrive pas à traiter les demandes, et le traitement des demandes ne progresse pas. Il en résulte un interblocage potentiel. Ce comportement peut être ajusté dans la console d'administration grâce à la propriété personnalisée ORB com.ibm.websphere.orb.threadPoolTimeout. Pour plus d'informations, voir la rubrique Propriétés personnalisées ORB (Object Request Broker).
Taille du fragment
L'ORB divise les messages en fragments pour les envoyer via sa connexion. Vous pouvez configurer la taille de ce fragment à l'aide du paramètre com.ibm.CORBA.FragmentSize.
- Dans la console d'administration, accédez à la page des propriétés de la fonction ORB et activez la trace ORB.
- Activez la trace ORBRas à partir de la page de consignation et de trace.
- Augmentez les tailles de fichiers de trace car la trace peut générer des volumes importants de données.
- Redémarrez le serveur et exécutez au moins une itération (de préférence plusieurs) du scénario à mesurer.
- Consultez le fichier de trace et effectuez une recherche sur Fragment
à suivre : Oui.
Ce message indique que l'ORB a transmis un fragment, mais qu'il lui en reste encore au moins un à envoyer pour que le message soit intégralement reçu. Une valeur Fragment à suivre : Non indique que le fragment donné est le dernier de tout le message. Ce fragment peut également être le premier si le message tient intégralement dans un fragment.
Si vous accédez à l'emplacement de Fragment à suivre : Oui, vous pouvez voir un bloc similaire à l'exemple suivant :
Fragment à suivre : Oui Taille du message : 4988 (0x137C) -- ID de demande : 1411
Cet exemple indique que la quantité de données du fragment est de 4988 octets et que l'ID demande est 1411. Si vous recherchez toutes les occurrences de ID demande : 1411, le nombre de fragments utilisés pour envoyer ce message est affiché. Si vous ajoutez les tailles de tous les messages associés, vous obtenez la taille totale du message envoyé via l'ORB.
- Vous pouvez configurer la taille du fragment en définissant la propriété personnalisée com.ibm.CORBA.FragmentSize.
Intercepteurs
Les intercepteurs sont des extensions de l'ORB qui peuvent configurer le contexte avant que l'ORB n'exécute une requête. Par exemple, le contexte peut inclure les transactions ou les sessions d'activité à importer. Si le client crée une transaction et transmet le contexte de transaction au serveur, celui-ci importe le contexte de transaction dans la requête serveur via les intercepteurs.
La plupart des clients ne lancent pas de transactions ni de sessions d'activité. Les intercepteurs inutiles peuvent donc être supprimés sur la plupart des systèmes.
Pour supprimer les intercepteurs, modifiez manuellement le fichier server.xml et supprimez les lignes correspondant aux intercepteurs inutiles dans la section relative à l'ORB.
Adaptation des paramètres de la cache des connexions
Selon la charge de travail du serveur d'applications et les contraintes de débit ou de temps de réponse, il peut s'avérer nécessaire d'adapter la taille de la cache des connexions de l'ORB. Chaque entrée de la cache des connexions est un objet qui représente un noeud final de socket TCP/IP distinct, identifié par le nom d'hôte ou l'adresse TCP/IP et le numéro de port utilisé par l'ORB pour envoyer une demande ou une réponse GIOP au noeud final cible éloigné. La cache des connexions permet de minimiser la durée nécessaire à l'établissement d'une connexion en réutilisant les objets de connexion de l'ORB pour des demandes ou des réponses ultérieures. (Le même socket TCP/IP est utilisé pour la demande et la réponse correspondante.)
Pour chaque serveur d'applications, le nombre d'entrées de la cache des connexions est directement lié au nombre des connexions d'ORB simultanées. Ces connexions sont constituées à la fois par les demandes entrantes émises par les clients éloignés et par les demandes sortantes émises par le serveur d'applications. Lorsque l'ORB côté serveur reçoit une demande de connexion, il utilise une connexion existante à partir d'une entrée de la cache ou établit une nouvelle connexion et ajoute une entrée correspondante dans la cache.
Les propriétés de taille maximale et minimale de la cache des connexions de l'ORB permettent de contrôler le nombre maximal et minimal d'entrées dans la cache des connexions à un instant donné. Lorsque le nombre d'entrées atteint la valeur spécifiée pour la propriété Taille maximale de la cache des connexions et qu'une nouvelle connexion est nécessaire, l'ORB crée la connexion demandée, ajoute une entrée à la cache et recherche les entrées de connexion inactives (5 au maximum) dans la cache afin de les supprimer. La nouvelle connexion étant ajoutée avant la suppression des entrées inactives, il est possible que le nombre d'entrées en cache dépasse temporairement la valeur spécifiée pour la propriété Taille maximale de la cache des connexions.
Une connexion d'ORB est considérée comme étant inactive si le flux de socket TCP/IP n'est pas utilisé et qu'aucune réponse GIOP n'est en attente pour des demandes lancées à l'aide de cette connexion. A mesure que la charge de travail de l'application diminue, l'ORB ferme les connexions et supprime les entrées correspondant à ces connexions dans la cache. L'ORB continue à supprimer des entrées dans la cache jusqu'à ce que le nombre d'entrées restantes soit égal ou inférieur à la valeur spécifiée pour la propriété Taille maximale de la cache des connexions. Le nombre d'entrées dans la cache n'est jamais inférieur à la valeur spécifiée pour la propriété Taille minimale de la cache des connexions, qui doit être inférieure de cinq unités à la valeur de la propriété Taille maximale de la cache des connexions.
Une adaptation de la cache des connexions dans l'ORB côté client n'est généralement pas nécessaire car seul un nombre réduit de connexions sont établies côté client.
Unités d'exécution du lecteur JNI
Par défaut, l'ORB utilise une unité d'exécution Java pour traiter chaque demande de connexion entrante qu'il reçoit. A mesure que le nombre de demandes simultanées s'accroît, l'espace de stockage consommé par un grand nombre d'unités d'exécution du lecteur augmente et peut créer un goulet d'étranglement dans les environnements où le nombre de ressources est restreint. A terme, le nombre d'unités d'exécution Java créées peut générer des exceptions de mémoire saturée si le nombre de demandes simultanées excède les ressources disponibles du système.
Pour éviter que ces erreurs se produisent, vous pouvez configurer l'ORB pour qu'il utilise les unités d'exécution du lecteur JNI où un nombre limité d'unités d'exécution du lecteur, implémentées à l'aide d'unités d'exécution de système d'exploitation natif et non d'unités d'exécution Java, est créé au cours de l'initialisation de l'ORB. Les unités d'exécution du lecteur JNI reposent sur le mécanisme asynchrone TCP/IP de système d'exploitation natif qui autorise une seule unité d'exécution de système d'exécution natif à gérer simultanément les événements d'E-S à partir de plusieurs sockets. L'ORB gère l'utilisation des unités d'exécution du lecteur JNI et affecte l'une des unités d'exécution disponibles à la gestion des demandes de connexion à l'aide d'un algorithme de permutation circulaire. En temps normal, les unités d'exécution JNI doivent être configurées uniquement lorsque les unités d'exécution Java utilisent trop de mémoire pour votre environnement d'application.
- Etant donné qu'un nombre fixe d'unités d'exécution est alloué, la capacité mémoire utilisée est réduite. Cette réduction est particulièrement avantageuse dans des environnements pour lesquels la charge de travail des demandes client est généralement importante et soutenue.
- Le temps de création et de suppression dynamiques des unités d'exécution Java est supprimé, car un nombre fixe d'unités d'exécution JNI est créé et attribué au cours de l'initialisation de l'ORB.
- Chaque unité d'exécution JNI peut gérer jusqu'à 1024 connexions de socket et interagit directement avec le mécanisme de système d'exploitation natif d'E-S asynchrone, ce qui peut augmenter les performances du traitement des E-S sur le réseau.