Informazioni sui risultati delle prestazioni
Il sistema utilizzato per i test è un cluster esteso Oracle Fusion Middleware (FMW) configurato nelle aree di Oracle Cloud Infrastructure (OCI) di Francoforte e Amsterdam.
Il dominio WebLogic è composto da 5 nodi distribuiti in diverse posizioni per consentire confronti delle prestazioni di varie topologie: server in esecuzione nello stesso dominio di disponibilità del database, server nella stessa area ma in domini di disponibilità diversi e server situati in un'area diversa.
Questi stress test sono stati eseguiti utilizzando la demo SOA Fusion Order (FOD) come applicazione SOA di esempio. La demo FOD è stata modificata per inserire messaggi JMS (Java Message Service) in una destinazione UUDD (Uniform Distributed Destination) al termine di un ordine. Questo esempio utilizza più adattatori SOA, ad esempio l'adattatore di file e l'adattatore JMS. Comprende anche diversi componenti SOA come Mediator, Business Process Execution Language (BPEL), Rules Engine e più funzioni WebLogic.
Il diagramma seguente mostra l'ambiente cluster esteso FMW utilizzato per i test:
prestazioni-env-oracle.zip allungate-fmw
I valori di latenza reali tra le reti in questo ambiente sono i seguenti:
| Tra host | Latenza media (RTT in ms) |
|---|---|
| Nello stesso dominio di disponibilità | 0.3 |
| Nella stessa area ma in un dominio di disponibilità diverso | 0.6 |
| In diverse regioni (Francoforte e Amsterdam) | 6.5 |
Esamina test di stress
Alcune delle configurazioni testate erano:
- Stress del cluster con due nodi attivi, applicazione di latenze diverse tra i server e tra uno dei server al database.
- Test dello stress dei singoli server, ciascuno con latenze diverse per il database.
- Esecuzione di test con entrambi i server collocati con il database (solo locale) e con entrambi i server posizionati in remoto dal database (solo remoto).
- Sottolineando il cluster con due nodi attivi in ogni area.
Per ogni configurazione sono stati testati carichi di lavoro diversi. Tutte le richieste di carico di lavoro vengono prima inviate al front-end, dove vengono distribuite (tramite il bilanciamento del carico globale, i load balancer locali, quindi i server Web) tra le istanze di Oracle WebLogic Server. La categoria del carico di lavoro (basso, medio, alto) dipende dal numero di nodi attivi in ogni impostazione ed è vincolata dai limiti di concorrenza del database. Ad esempio, 80 utenti virtuali concorrenti verranno considerati un carico di lavoro basso per i server WebLogic se sono in esecuzione quattro nodi, ma un carico di lavoro elevato se è attivo un solo nodo. Tuttavia, dal punto di vista del database, il carico di lavoro rimane lo stesso. Per semplicità, i carichi di lavoro utilizzati sono i seguenti:
- Carichi di lavoro bassi (20 utenti virtuali concorrenti per server WebLogic, con un massimo di 40 utenti virtuali concorrenti totali nel sistema)
- Carichi di lavoro medi (40-60 utenti virtuali concorrenti per server WebLogic, con un massimo di 120 utenti virtuali concorrenti totali nel sistema)
- Carichi di lavoro elevati (80 utenti virtuali concorrenti per server WebLogic, con un massimo di 160 utenti virtuali concorrenti totali nel sistema)
Sulla base dei risultati dello stress test, queste sono le conclusioni:
- Prestazioni globali del cluster
Prestazioni complessive del cluster (in termini di throughput WebLogic, transazioni al secondo (TX/sec)) per un cluster con 2 server:
- Quando entrambi i server si trovano nello stesso dominio di disponibilità (AD) (preso come riferimento): 100%
- Quando ogni server si trova in AD diversi: ~100%
- Quando un server si trova in un'area diversa (6.5ms tempo di andata e ritorno (RTT)): 90-95%
- Quando entrambi i server si trovano in un'area diversa da quella del DB (6.5ms RTT): 85-95%
- Prestazioni per server
Le prestazioni per server (in termini di throughput WebLogic, TX/sec):
- Per il server nello stesso dominio di disponibilità del database (preso come riferimento): 100%
- Per il server nell'altro AD: 98-99%
- Per il server nell'altra regione: 85-90%
- Numero di connessioni all'origine dati attive
Il numero di connessioni all'origine dati attive aumenta con una latenza più elevata al database. Anche se dipende dal carico di lavoro, il server nell'area 2 mostra fino a 2x connessioni attive rispetto al server collocato con il database. Considerare questa opzione per un dimensionamento corretto delle origini dati e delle sessioni del database WebLogic.
- Transazioni JTA
Le transazioni JTA rimangono attive per periodi più lunghi nei server con latenza più elevata al database. Le transazioni che rimangono attive per periodi più lunghi hanno maggiori probabilità di essere influenzate dagli errori. Di conseguenza, diventa particolarmente importante in questi sistemi che i log delle transazioni utilizzino le aree di memorizzazione persistenti JDBC. Per gli errori del server, la migrazione del servizio dovrebbe avvenire e il ripristino avverrà automaticamente.
- Latenza tra più aree
Per una latenza tra più aree di 6.5ms RTT e l'implementazione delle best practice fornite da questo documento per i cluster estesi FMW:
- Riduzione delle prestazioni ridotta mediante un cluster esteso (~10%).
- Si verifica un degrado delle prestazioni simile per un cluster con un server in ogni area e un cluster con entrambi i server nell'area remota. Questo perché la comunicazione intra-cluster è influenzata anche dalla latenza.
- Latenza tra più AD
La latenza tra più AD (0.6ms) non ha un impatto significativo sulle prestazioni complessive di un sistema FOD SOA.
Nota
Tenendo presente tutto quanto sopra e tenendo conto delle sanzioni per le prestazioni osservate in molti test, Oracle non supporta i cluster estesi di Oracle Fusion Middleware che superano i 10 millisecondi di latenza (RTT) tra i siti. I sistemi possono funzionare senza problemi, ma i tempi di transazione aumenteranno notevolmente. Anche le latenze oltre i 10 millisecondi (RTT) causeranno problemi nel cluster di Oracle Coherence utilizzato per la distribuzione e JT, i servizi Web o i timeout delle applicazioni. Ciò rende le soluzioni presentate in questo playbook adatte principalmente a siti o regioni con bassa latenza tra loro.
Quando si evidenzia un cluster con 2 nodi, il grafico seguente mostra le prestazioni complessive del cluster, a seconda della posizione dei server. Il riferimento (100%) è quando entrambi i server vengono eseguiti nello stesso dominio di disponibilità del database.
Quando si sottolinea un cluster con 2 nodi, il grafico seguente mostra le prestazioni per il server che non è collocato con il database (si trova nell'altro AD o in un'area remota) rispetto alle prestazioni del server che è collocato con il database:
Quando si esegue lo stressing di un cluster con 2 nodi, questi grafici mostrano il numero di connessioni all'origine dati attive (media) per ciascun server. Un server è sempre collocato con il database (site1) e l'altro server si trova a valori di latenza diversi dal database (site2):
Quando si esegue lo stressing di un singolo server con latenze di database diverse, vengono osservati i risultati delle prestazioni riportati di seguito, rispetto a un server che è co-locato con il database, con un carico medio-alto. Il riferimento (100%) è quando il server si trova nello stesso dominio di disponibilità del database.
Quando si esegue lo stressing di un singolo server con latenze diverse per il database, si tratta delle connessioni alle origini dati attive con stress da medio a elevato:
Quando si esegue lo stressing di un singolo server con latenze diverse rispetto al database, l'immagine seguente mostra il tempo medio di attività JTA per latenze diverse rispetto al database:
Quando si confrontano le prestazioni di un cluster con entrambi i server nella stessa area del database (solo locale) rispetto a un cluster con entrambi i server in un'area diversa dal database (solo remoto), vengono osservati i risultati delle prestazioni riportati di seguito. Il riferimento (100%) è il cluster solo locale.
La figura seguente mostra il tempo medio di attività di JTA TX per un cluster con entrambi i server in esecuzione nella stessa area del database (solo locale) e un cluster in cui sono in esecuzione entrambi i server in un'area diversa dal database (solo remoto).
Ora inizio revisione
Si prevedono ritardi diversi in base alle impostazioni di capacità iniziali nelle origini dati. Per impostazione predefinita, la maggior parte delle origini dati Oracle Fusion Middleware (FMW) utilizza una capacità iniziale pari a zero per il connection pool. Tuttavia, per ridurre il tempo di risposta del sistema durante il normale funzionamento di runtime, può essere utile aumentare la capacità iniziale del pool. Tuttavia, in un cluster esteso, i server che risiedono in remoto nel database mostreranno una maggiore latenza all'avvio man mano che viene utilizzata una maggiore capacità iniziale del pool.
È necessaria una decisione equilibrata tra l'ottimizzazione dei tempi di risposta durante il normale funzionamento e la riduzione al minimo dell'ora di inizio per determinare le impostazioni di capacità iniziali ideali. Poiché la capacità iniziale è configurata a livello di origine dati (connection pool), queste impostazioni influiscono sul tempo di avvio di tutti i server all'interno del cluster (quelli locali del database e quelli remoti).
Il grafico seguente mostra le ore di inizio del server WebLogic man mano che la latenza per il database aumenta, per valori di dimensione iniziali diversi in tutte le origini dati (11 origini dati in totale):
Rivedi tempi di migrazione servizio JMS
Tuttavia, il tempo necessario per un'operazione di migrazione del servizio dall'area 1 all'area 2 può aumentare a causa della latenza al database. Questo aumento è causato dal tempo impiegato per recuperare i messaggi nell'altro server, poiché vengono letti dall'area di memorizzazione persistente nel database nell'altra area.
L'incremento è maggiore se le aree di memorizzazione persistenti dispongono di un numero elevato di messaggi in sospeso. Per i messaggi JMS con una dimensione di 2,7 KB ciascuno, l'immagine riportata di seguito mostra i tempi di migrazione del servizio JMS quando una delle aree di memorizzazione persistenti contiene un numero elevato di messaggi in sospeso (circa 8000) e il servizio viene migrato da un server collocato con il database a un altro server, per diverse latenze tra il server di destinazione e il database:
L'immagine riportata di seguito mostra l'incremento del tempo di migrazione del servizio (%) con un numero elevato di messaggi in sospeso (circa 8000) per diverse latenze tra il server di destinazione e il database. Il riferimento (100%) si verifica quando il servizio esegue la migrazione a un server che si trova nello stesso dominio di disponibilità (AD) del database.
L'immagine seguente mostra i tempi di migrazione per lo stesso caso, ma con un basso numero di messaggi in sospeso (circa 50) per latenze diverse tra il server di destinazione e il database.
L'immagine riportata di seguito mostra l'incremento del tempo di migrazione del servizio JMS (%) con un numero ridotto di messaggi in sospeso (circa 50) per latenze diverse tra il server di destinazione e il database. Il riferimento (100%) si verifica quando il servizio esegue la migrazione a un server che si trova nello stesso dominio di disponibilità del database.
Rivedi tempi di distribuzione composti SOA
Durante la distribuzione di un composto (distribuzione della prima versione o aggiornamento a una versione più recente), il composto può essere distribuito in precedenza ai server nell'area 1 rispetto ai server nell'area 2, anche se non verrà attivato formalmente finché non sarà disponibile in tutti i membri del cluster.
L'immagine seguente mostra l'aumento del tempo impiegato per caricare un composto in un server durante l'avvio del server, con latenza al database rispetto al tempo impiegato per caricarlo in un server che risiede nello stesso dominio di disponibilità (AD) del database. La dimensione del composto è di 365 KB.
L'immagine riportata di seguito mostra l'aumento del tempo impiegato per distribuire un composto con i comandi Oracle WebLogic Scripting Tool (WLST), per diverse latenze dal server che esegue la distribuzione nel database.
Rivedi traffico tra siti
Questo isolamento, tuttavia, è non deterministico (ad esempio, c'è spazio per scenari di failover in cui un richiamo di Java Message Service (JMS) potrebbe avvenire attraverso i due siti). Detto questo, per un'applicazione tipica, la maggior parte del traffico avviene tra le istanze di Oracle WebLogic Server e il database. Questa sarà la chiave per le prestazioni della topologia dei cluster estesi di Oracle Fusion Middleware (FMW). Questa immagine mostra la percentuale di traffico tra un server WebLogic nell'area 2 e i diversi indirizzi nell'area 1 durante uno stress test. Si noti che oltre il 90% del traffico avviene tra il server e il database, che si trova nell'area 1.
Per acquisire la quantità di traffico per IP tra i siti, è possibile utilizzare lo strumento iftop. Ad esempio:
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900L'immagine seguente mostra la percentuale di traffico tra un server WebLogic nell'area 2 e i diversi indirizzi nell'area 1 durante un test di stress.
