À propos des résultats de performance
Le système utilisé pour les tests est une grappe étendue Oracle Fusion Middleware (FMW) configurée dans les régions Oracle Cloud Infrastructure (OCI) de Francfort et d'Amsterdam.
Le domaine WebLogic se compose de 5 noeuds répartis dans différents emplacements pour permettre des comparaisons de performance sur différentes topologies : serveurs exécutés dans le même domaine de disponibilité que la base de données, serveurs dans la même région mais dans différents domaines de disponibilité et serveurs situés dans une région différente.
Ces tests de résistance ont été effectués à l'aide de la démonstration SOA Fusion Order Demo (FOD) en tant qu'exemple d'application SOA. La démo FOD a été modifiée pour insérer des messages JMS (Java Message Service) dans une destination UDD (Uniform Distributed Destination) lorsqu'une commande est terminée. Cet exemple est très gourmand en bases de données et utilise plusieurs adaptateurs SOA tels que l'adaptateur de fichiers et l'adaptateur JMS. Il implique également différents composants SOA, tels que le composant Mediator, le langage BPEL Process Execution Language (Business Process Execution Language), le moteur de règles et plusieurs fonctionnalités WebLogic.
Le diagramme suivant présente 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'augmentation (RTT en ms) |
|---|---|
| Dans le même domaine de disponibilité | 0,3 |
| Dans la même région, mais dans un domaine de disponibilité différent | 0,6 |
| Dans différentes régions (Francfort et Amsterdam) | 6,5 |
Réviser les tests de crise
Certaines des configurations testées étaient :
- Stresser le cluster avec deux nœuds en haut, en appliquant des latences différentes entre les serveurs et entre l'un des serveurs à la base de données.
- Stress testant des serveurs individuels, chacun 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 seulement) et avec les deux serveurs situés à distance de la base de données (distante seulement).
- Mise en tension de la grappe 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 de travail sont d'abord envoyées à l'extrémité frontale, où elles sont réparties (au moyen de l'équilibrage de charge global, des équilibreurs de charge locaux, puis des 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 d'accès simultané de la base de données. Par exemple, 80 utilisateurs virtuels simultanés seraient considérés comme une charge de travail faible pour les serveurs WebLogic si quatre noeuds s'exécutent, mais 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 de travail reste la même. Pour simplifier, 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 :
- Performance globale de la grappe
Performance globale de la grappe (en termes de débit WebLogic, transactions par seconde (TX/s)) pour une grappe 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 domaine de disponibilité différent : ~100 %
- Lorsqu'un serveur se trouve dans une autre région (6.5ms round-trip time (RTT)) : 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 %
- Performance par serveur
Performance 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 dans l'autre AD : 98-99%
- Pour le serveur dans l'autre région : 85-90%
- Nombre de connexions actives à la source de données
Le nombre de connexions actives à une source de données augmente avec une latence plus élevée pour la base de données. Bien que cela dépende de la charge de travail, le serveur de la région 2 affiche jusqu'à 2x connexions actives que le serveur colocalisé avec la base de données. Considérez cela 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 de longues périodes 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. Pour les pannes de serveur, la migration de service doit avoir lieu et la récupération se fera automatiquement.
- Latence inter-région
Pour une latence inter-régions de 6.5ms RTT et la mise en œuvre des meilleures pratiques fournies par le présent document pour les grappes FMW Stretched :
- La dégradation des performances est faible à l'aide d'un cluster étiré (~10%).
- Il existe une dégradation des performances similaire pour un cluster avec un serveur dans chaque région et un cluster avec les deux serveurs dans la région distante. En effet, la communication intra-grappe est également affectée par la latence.
- Latence entre domaines de disponibilité
La latence interdomaine de disponibilité (0.6ms) n'a pas d'incidence significative sur la performance globale d'un système SOA FOD.
Note :
Compte tenu de tout ce qui précède et des pénalités de performance observées dans de nombreux tests, Oracle ne prend pas en charge les grappes étendues d'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. Les latences supérieures à 10 millisecondes (RTT) entraîneront également des problèmes dans la grappe Oracle Coherence utilisée pour le déploiement et JT, les services Web ou les temporisations d'application. Cela rend les solutions présentées dans ce livre de jeu adaptées principalement aux sites ou régions à faible latence entre eux.
Lorsque vous mettez en surbrillance un cluster avec 2 noeuds, le graphique suivant montre les performances globales du cluster, en fonction de l'emplacement des serveurs. La référence (100 %) est lorsque les deux serveurs s'exécutent dans le même domaine de disponibilité que la base de données.
Lorsque vous mettez en surbrillance un cluster avec 2 noeuds, le graphique suivant montre 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 mettez en surbrillance une grappe avec 2 noeuds, ces graphiques indiquent le nombre de connexions actives à la source de données (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) :
Lorsque vous mettez en surbrillance un serveur unique avec des latences de base de données différentes, les résultats de performance suivants sont observés, par rapport à un serveur qui est colocalisé avec la base de données, avec 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 soumises à des contraintes moyennes à élevées :
Lors de la sollicitation d'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 des latences différentes pour la base de données :
Lorsque vous comparez les performances d'une grappe avec les deux serveurs de la même région que la base de données (locale uniquement) par rapport à une grappe avec les deux serveurs d'une région différente de celle de la base de données (distante uniquement), les résultats de performance suivants sont observés. La référence (100 %) est la grappe locale uniquement.
La figure suivante illustre le temps d'activité moyen de JTA TX pour un cluster dont les deux serveurs s'exécutent 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 celle de la base de données (distante uniquement).
Réviser les temps de démarrage
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 réserve de connexions. Toutefois, pour réduire le temps de réponse du système pendant l'exécution normale, 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. Étant donné que la capacité initiale est configurée au niveau de la source de données (groupe de connexions), ces paramètres influencent le temps de démarrage de tous les serveurs du cluster (ceux qui sont locaux à la base de données et ceux qui sont distants).
Le graphique suivant montre les heures de début du serveur WebLogic lorsque 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 du service JMS
Toutefois, le temps nécessaire pour 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 montre les temps de migration du service JMS lorsque l'un des espaces de stockage persistants contient 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 du 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 au moment où le service migre vers un serveur qui se trouve dans le même domaine de disponibilité que la base de données.
L'image suivante montre 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 des latences différentes entre le serveur de destination et la base de données. La référence (100 %) est lorsque le service migre vers un serveur qui se trouve dans le même domaine de disponibilité que la base de données.
Vérifier les temps de déploiement du composite 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'illustration suivante présente l'augmentation du temps nécessaire pour charger un composite dans un serveur au cours du démarrage du serveur, avec une latence pour la base de données par rapport au temps nécessaire pour le charger 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 montre l'augmentation du temps nécessaire pour déployer un composite avec les commandes Oracle WebLogic Scripting Tool (WLST), pour des latences différentes du serveur qui effectue le déploiement vers la base de données.
Vérifier le trafic entre les sites
Toutefois, cet isolement n'est pas déterministe (par exemple, il y a de la place pour les scénarios de basculement où un appel JMS (Java Message Service) pourrait avoir lieu sur les deux sites). Cela dit, pour une application type, la majeure partie du trafic est effectuée entre les instances Oracle WebLogic Server et la base de données. Ce sera la clé de la performance de la topologie de grappes étendues Oracle Fusion Middleware (FMW). Cette image montre le pourcentage du trafic entre un serveur WebLogic dans la région 2 et les différentes adresses dans 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, située dans la région 1.
Pour capturer la quantité de trafic par IP entre les sites, vous pouvez utiliser l'outil iftop. Par exemple :
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900L'image suivante montre le pourcentage de trafic entre un serveur WebLogic dans la région 2 et les différentes adresses dans la région 1 lors d'un test de résistance.
