A propos des résultats de performance
Le système utilisé pour les tests est un cluster étendu Oracle Fusion Middleware (FMW) configuré dans les régions Oracle Cloud Infrastructure (OCI) de Francfort et d'Amsterdam.
Le domaine WebLogic se compose de 5 noeuds répartis sur différents emplacements pour permettre la comparaison des performances de différentes topologies : serveurs exécutés dans le même domaine de disponibilité que la base de données, serveurs de la même région mais dans différents domaines de disponibilité et serveurs situés dans une autre région.
Ces tests de résistance ont été effectués à l'aide de la démonstration de commande SOA Fusion (FOD) en tant qu'exemple d'application SOA. La démonstration du FOD a été modifiée pour insérer des messages JMS (Java Message Service) dans une destination de destination distribuée uniforme (UDD) lorsqu'une commande est terminée. Cet exemple est très gourmand en base de données et utilise plusieurs adaptateurs SOA tels que l'adaptateur de fichiers et l'adaptateur JMS. Elle implique également différents composants SOA tels que Mediator, BPEL (Business Process Execution Language), le moteur de règles et plusieurs fonctionnalités WebLogic.
Le schéma suivant illustre l'environnement de cluster étendu FMW utilisé pour les tests :
fmw-stretched-performance-env-oracle.zip
Les valeurs de latence réelles entre les réseaux de cet environnement étaient les suivantes :
| Entre les hôtes | Latence d'évolution (RTT en ms) |
|---|---|
| Dans le même domaine | 0.3 |
| Dans la même région mais dans un autre domaine de disponibilité | 0.6 |
| Dans différentes régions (Francfort et Amsterdam) | 6.5 |
Vérifier les tests de stress
Certaines des configurations testées étaient :
- Mise en évidence du cluster avec deux noeuds en cours, application de latences différentes entre les serveurs et entre l'un des serveurs à la base de données.
- Test de stress sur des serveurs individuels avec des latences différentes pour la base de données.
- Exécution de tests avec les deux serveurs colocalisés avec la base de données (locale uniquement) et avec les deux serveurs situés à distance de la base de données (distante uniquement).
- Mise en évidence du cluster avec deux noeuds actifs dans chaque région.
Pour chaque configuration, différentes charges de travail ont été testées. Toutes les demandes de charge globale sont d'abord envoyées vers le front-end, où elles sont distribuées (via l'équilibrage de charge global, puis les équilibreurs de charge locaux, puis les serveurs Web) entre les instances Oracle WebLogic Server. La catégorie de charge globale (faible, moyenne, élevée) dépend du nombre de noeuds actifs dans chaque configuration et est limitée par les limites de simultanéité de la base de données. Par exemple, 80 utilisateurs virtuels simultanés sont considérés comme une charge de travail faible pour les serveurs WebLogic s'il y a quatre noeuds en cours d'exécution, mais comme une charge de travail élevée si un seul noeud est actif. Toutefois, du point de vue de la base de données, la charge globale reste la même. Pour plus de simplicité, les charges de travail utilisées sont les suivantes :
- Charges de travail faibles (20 utilisateurs virtuels simultanés par serveur WebLogic, avec un maximum de 40 utilisateurs virtuels simultanés dans le système)
- Charges de travail moyennes (40 à 60 utilisateurs virtuels simultanés par serveur WebLogic, avec un maximum de 120 utilisateurs virtuels simultanés dans le système)
- Charges de travail élevées (80 utilisateurs virtuels simultanés par serveur WebLogic, avec un maximum de 160 utilisateurs virtuels simultanés dans le système)
Sur la base des résultats des tests de résistance, voici les conclusions :
- Performances globales du cluster
Performances globales du cluster (en termes de débit WebLogic, transactions par seconde (TX/s)) pour un cluster avec 2 serveurs :
- Lorsque les deux serveurs se trouvent dans le même domaine de disponibilité (pris comme référence) : 100 %
- Lorsque chaque serveur se trouve dans un autre domaine de disponibilité : ~100 %
- Lorsqu'un serveur se trouve dans une autre région (6.5ms aller-retour) : 90 à 95 %
- Lorsque les deux serveurs se trouvent dans une région différente de la base de données (6.5ms RTT) : 85 à 95 %
- Performances par serveur
Performances par serveur (en termes de débit WebLogic, TX/s) :
- Pour le serveur dans le même domaine de disponibilité que la base de données (pris comme référence) : 100 %
- Pour le serveur de l'autre domaine de disponibilité : 98-99 %
- Pour le serveur de l'autre région : 85-90 %
- Nombre de connexions de source de données actives
Le nombre de connexions de source de données actives augmente avec une latence plus élevée pour la base de données. Bien que cela dépende de la charge globale, le serveur de la région 2 affiche jusqu'à 2x connexions actives que le serveur colocalisé avec la base de données. Considérez ceci pour un dimensionnement correct des sources de données et des sessions de base de données WebLogic.
- Transactions JTA
Les transactions JTA restent actives pendant des périodes plus longues sur les serveurs avec une latence plus élevée pour la base de données. Les transactions qui restent actives pendant de longues périodes sont plus susceptibles d'être affectées par des échecs. Par conséquent, il est particulièrement important dans ces systèmes que les journaux de transactions utilisent des espaces de stockage persistants JDBC. En cas de panne du serveur, la migration du service doit avoir lieu et la récupération se fera automatiquement.
- Latence inter-région
Pour une latence inter-région de 6.5ms RTT et l'implémentation des meilleures pratiques fournies par ce document pour les clusters étendus FMW :
- La dégradation des performances est faible avec un cluster étendu (environ 10 %).
- La dégradation des performances d'un cluster comportant un serveur dans chaque région et un cluster comportant les deux serveurs dans la région distante est similaire. En effet, la communication intra-cluster est également affectée par la latence.
- Latence inter-AD
La latence inter-AD (0.6ms) n'a pas d'impact significatif sur les performances globales d'un système SOA FOD.
Remarques :
Compte tenu de tout ce qui précède et des pénalités de performances observées dans de nombreux tests, Oracle ne prend pas en charge les clusters étendus Oracle Fusion Middleware qui dépassent 10 millisecondes de latence (RTT) entre les sites. Les systèmes peuvent fonctionner sans problème, mais les temps de transaction augmenteront considérablement. Des latences supérieures à 10 millisecondes (RTT) entraîneront également des problèmes dans le cluster Oracle Coherence utilisé pour le déploiement et JT, les services Web ou les délais d'expiration des applications. Cela rend les solutions présentées dans ce livre de jeux adaptées principalement aux sites ou régions à faible latence entre eux.
Lors de la mise en évidence d'un cluster à 2 noeuds, le graphique suivant présente les performances globales du cluster, en fonction de l'emplacement des serveurs. La référence (100 %) est lorsque les deux serveurs sont exécutés dans le même domaine de disponibilité que la base de données.
Lorsque vous insistez sur un cluster à 2 noeuds, le graphique suivant indique les performances du serveur qui n'est pas colocalisé avec la base de données (il se trouve dans l'autre domaine de disponibilité ou dans une région distante) par rapport aux performances du serveur colocalisé avec la base de données :
Lorsque vous stressez un cluster avec 2 noeuds, ces graphiques indiquent le nombre de connexions de source de données actives (moyenne) pour chaque serveur. Un serveur est toujours colocalisé avec la base de données (site1) et l'autre serveur a des valeurs de latence différentes de celles de la base de données (site2) :
Lors de la contrainte d'un serveur unique avec des latences de base de données différentes, les résultats de performances suivants sont observés, par rapport à un serveur co-localisé avec la base de données, sous une charge moyenne à élevée. La référence (100 %) est lorsque le serveur se trouve dans le même domaine de disponibilité que la base de données.
Lors de la sollicitation d'un serveur unique avec des latences différentes pour la base de données, il s'agit des connexions de source de données actives sous une contrainte moyenne à élevée :
Lorsque vous définissez un serveur unique avec des latences différentes pour la base de données, l'image suivante montre le temps d'activité JTA moyen pour différentes latences pour la base de données :
Lorsque vous comparez les performances d'un cluster avec les deux serveurs de la même région que la base de données (locale uniquement) par rapport à un cluster avec les deux serveurs d'une région différente de celle de la base de données (distante uniquement), les résultats de performances suivants sont observés. La référence (100 %) est le cluster local uniquement.
La figure suivante présente le temps d'activité JTA TX moyen pour un cluster dont les deux serveurs sont exécutés dans la même région que la base de données (locale uniquement) et un cluster exécutant les deux serveurs dans une région différente de la base de données (distante uniquement).
Heures de début de la révision
Différents retards sont attendus en fonction des paramètres de capacité initiaux dans les sources de données. Par défaut, la plupart des sources de données Oracle Fusion Middleware (FMW) utilisent une capacité initiale nulle pour leur pool de connexions. Toutefois, pour réduire le temps de réponse du système lors d'un fonctionnement normal, il peut être avantageux d'augmenter la capacité initiale du pool. Toutefois, dans un cluster étendu, les serveurs qui résident à distance dans la base de données affichent une latence accrue au démarrage, car une capacité de pool initiale plus élevée est utilisée.
Une décision équilibrée est nécessaire entre l'optimisation des temps de réponse pendant le fonctionnement normal et la minimisation de l'heure de début pour déterminer les paramètres de capacité initiale idéaux. Etant donné que la capacité initiale est configurée au niveau de la source de données (pool de connexions), ces paramètres influent sur le temps de démarrage de tous les serveurs du cluster (ceux qui sont locaux à la base de données et ceux qui y sont distants).
Le graphique suivant présente les heures de démarrage du serveur WebLogic à mesure que la latence de la base de données augmente, pour différentes valeurs de taille initiale dans toutes les sources de données (11 sources de données au total) :
Vérifier les temps de migration des services JMS
Toutefois, le temps nécessaire à une opération de migration de service de la région 1 vers la région 2 peut augmenter en raison de la latence de la base de données. Cette augmentation est due au temps passé à récupérer les messages sur l'autre serveur, car ils sont lus à partir de l'espace de stockage persistant dans la base de données de l'autre région.
L'incrément est plus élevé si les espaces de stockage persistants contiennent un grand nombre de messages en attente. Pour les messages JMS d'une taille de 2,7 ko chacun, l'image suivante présente les temps de migration du service JMS lorsque l'un des espaces de stockage persistants comporte un nombre élevé de messages en attente (environ 8000) et que le service migre d'un serveur colocalisé avec la base de données vers un autre serveur, pour des latences différentes entre le serveur de destination et la base de données :
L'image suivante présente l'incrément de temps de migration de service (%) avec un nombre élevé de messages en attente (environ 8000) pour différentes latences entre le serveur de destination et la base de données. La référence (100 %) correspond à la migration du service vers un serveur se trouvant dans le même domaine de disponibilité que la base de données.
L'image suivante présente les temps de migration pour le même cas, mais avec un faible nombre de messages en attente (environ 50) pour des latences différentes entre le serveur de destination et la base de données.
L'image suivante présente l'incrément de temps de migration du service JMS (%) avec un faible nombre de messages en attente (environ 50) pour différentes latences entre le serveur de destination et la base de données. La référence (100 %) est le moment où le service migre vers un serveur situé dans le même domaine de disponibilité que la base de données.
Vérifier les temps de déploiement des composites SOA
Lors du déploiement d'un composite (déploiement de sa première version ou mise à jour vers une version plus récente), le composite peut être déployé plus tôt sur les serveurs de la région 1 que sur les serveurs de la région 2, bien qu'il ne soit pas officiellement activé tant qu'il n'est pas disponible dans tous les membres du cluster.
L'image suivante illustre l'augmentation du temps nécessaire au chargement d'un composite dans un serveur au démarrage, avec une latence pour la base de données par rapport au temps nécessaire au chargement dans un serveur qui réside dans le même domaine de disponibilité que la base de données. La taille du composite est de 365 ko.
L'image suivante illustre l'augmentation du temps de déploiement d'un composite à l'aide des commandes WLST (Oracle WebLogic Scripting Tool), pour différentes latences par rapport au serveur qui effectue le déploiement dans la base de données.
Vérifier le trafic entre les sites
Toutefois, cet isolement n'est pas déterministe (par exemple, il existe des scénarios de basculement dans lesquels un appel JMS (Java Message Service) pourrait avoir lieu sur les deux sites). Par conséquent, pour une application standard, la majeure partie du trafic s'effectue entre les instances Oracle WebLogic Server et la base de données. Il s'agit de la clé des performances de la topologie des clusters étendus d'Oracle Fusion Middleware (FMW). Cette image montre le pourcentage de trafic entre un serveur WebLogic de la région 2 et les différentes adresses de la région 1 lors d'un test de résistance. Notez que plus de 90 % du trafic se produit entre le serveur et la base de données, qui se trouve dans la région 1.
Pour capturer la quantité de trafic par IP entre les sites, vous pouvez utiliser l'outil iftop. Exemple :
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900L'image suivante montre le pourcentage de trafic entre un serveur WebLogic de la région 2 et les différentes adresses de la région 1 lors d'un test de résistance.
