Informationen zu Performanceergebnissen
Das für die Tests verwendete System ist ein gestrecktes Oracle Fusion Middleware-(FMW-)Cluster, das in den Oracle Cloud Infrastructure-(OCI-)Regionen Frankfurt und Amsterdam konfiguriert ist.
Die Domain WebLogic besteht aus 5 Knoten, die über verschiedene Standorte verteilt sind, um Performancevergleiche verschiedener Topologien zu ermöglichen: Server, die in derselben Availability-Domain wie die Datenbank ausgeführt werden, Server in derselben Region, aber in verschiedenen Availability-Domains und Server, die sich in einer anderen Region befinden.
Diese Stresstests wurden mit der SOA Fusion Order Demo (FOD) als SOA-Beispielanwendung durchgeführt. Die FOD-Demo wurde geändert, um Java Message Service-(JMS-)Nachrichten in ein Uniform Distributed Destination-(UDD-)Ziel einzufügen, wenn eine Bestellung abgeschlossen ist. Dieses Beispiel ist sehr datenbankintensiv und verwendet mehrere SOA-Adapter wie File Adapter und JMS Adapter. Es umfasst auch verschiedene SOA-Komponenten wie Mediator, Business Process Execution Language (BPEL), Rules Engine und mehrere WebLogic-Features.
Das folgende Diagramm zeigt die gestreckte FMW-Clusterumgebung, die für die Tests verwendet wird:
fmw-stretched-performance-env-oracle.zip
Die tatsächlichen Latenzwerte zwischen den Netzwerken in dieser Umgebung waren:
| Zwischen Hosts | Avgerage Latenz (RTT in ms) |
|---|---|
| In derselben Availability-Domain | 0.3 |
| In derselben Region, aber in einer anderen Availability-Domain | 0.6 |
| In verschiedenen Regionen (Frankfurt und Amsterdam) | 6.5 |
Stresstests prüfen
Einige der getesteten Konfigurationen waren:
- Das Cluster wird mit zwei Knoten belastet, wobei verschiedene Latenzzeiten zwischen den Servern und zwischen einem der Server auf die Datenbank angewendet werden.
- Stresstests einzelner Server, die jeweils unterschiedliche Latenzen zur Datenbank aufweisen.
- Ausführen von Tests mit beiden Servern, die mit der Datenbank kollokiert sind (nur lokal) und mit beiden Servern, die sich entfernt von der Datenbank befinden (nur Remote).
- Cluster mit zwei Knoten belasten, die in jeder Region aktiv sind
Für jede Konfiguration wurden verschiedene Workloads getestet. Alle Workload-Anforderungen werden zuerst an das Frontend gesendet, wo sie (über das globale Load Balancing, dann die lokalen Load Balancer und dann die Webserver) auf die Oracle WebLogic Server-Instanzen verteilt werden. Die Workload-Kategorie (niedrig, mittel, hoch) hängt von der Anzahl der aktiven Knoten in jedem Setup ab und wird durch die Grenzwerte für den gleichzeitigen Zugriff der Datenbank eingeschränkt. Beispiel: 80 gleichzeitige virtuelle Benutzer würden als niedrige Workload für WebLogic-Server betrachtet, wenn vier Knoten ausgeführt werden, aber eine hohe Workload, wenn nur ein Knoten aktiv ist. Aus der Sicht der Datenbank bleibt die Arbeitslast jedoch gleich. Der Einfachheit halber werden folgende Workloads verwendet:
- Geringe Workloads (20 gleichzeitige virtuelle Benutzer pro WebLogic-Server, maximal 40 gleichzeitige virtuelle Benutzer im System)
- Mittlere Workloads (40 bis 60 gleichzeitige virtuelle Benutzer pro WebLogic-Server, maximal 120 gleichzeitige virtuelle Benutzer im System)
- Hohe Workloads (80 gleichzeitige virtuelle Benutzer pro WebLogic-Server, mit maximal 160 gleichzeitigen virtuellen Benutzern im System)
Basierend auf den Stresstestergebnissen sind dies die Schlussfolgerungen:
- Gesamt-Clusterperformance
Die Gesamt-Clusterperformance (in Bezug auf WebLogic-Durchsatz, Transaktionen pro Sekunde (TX/s)) für ein Cluster mit 2 Servern:
- Wenn sich beide Server in derselben Availability-Domain (AD) befinden (als Referenz verwendet): 100%
- Wenn sich jeder Server in einer anderen AD befindet: ~100%
- Wenn sich ein Server in einer anderen Region befindet (6.5ms Roundtrip Time (RTT)): 90-95%
- Wenn sich beide Server in einer anderen Region als die DB befinden (6.5ms RTT): 85-95%
- Leistung pro Server
Die Leistung pro Server (in Bezug auf WebLogic-Durchsatz, TX/s):
- Für den Server in derselben AD wie DB (als Referenz verwendet): 100%
- Für den Server in der anderen AD: 98-99%
- Für den Server in der anderen Region: 85-90%
- Anzahl aktive Datenquellenverbindungen
Die Anzahl der aktiven Datenquellenverbindungen nimmt mit einer höheren Latenz zur Datenbank zu. Obwohl es von der Workload abhängt, zeigt der Server in Region 2 bis zu 2x aktive Verbindungen an als der Server, der mit der Datenbank kollokiert ist. Berücksichtigen Sie dies für eine korrekte Größe der WebLogic-Datenquellen und Datenbanksessions.
- JTA-Transaktionen
Die JTA-Transaktionen bleiben länger auf Servern mit höherer Latenz für die Datenbank aktiv. Transaktionen, die länger aktiv bleiben, sind eher von Fehlern betroffen. Daher wird es in diesen Systemen besonders wichtig, dass Transaktionslogs persistente JDBC-Speicher verwenden. Bei Serverausfällen sollte die Servicemigration erfolgen, und das Recovery erfolgt automatisch.
- Regionsübergreifende Latenz
Für eine regionsübergreifende Latenz von 6.5ms RTT und die Implementierung von Best Practices, die in diesem Dokument für die FMW Stretched-Cluster bereitgestellt werden:
- Bei Verwendung eines gestreckten Clusters (~10%) ist die Performance gering.
- Bei einem Cluster mit einem Server in jeder Region und einem Cluster mit beiden Servern in der Remoteregion kommt es zu einer ähnlichen Performancebeeinträchtigung. Dies liegt daran, dass die Intra-Cluster-Kommunikation auch von der Latenz betroffen ist.
- AD-übergreifende Latenz
Die Cross-AD-Latenz (0.6ms) hat keine wesentlichen Auswirkungen auf die Gesamtperformance eines SOA-FOD-Systems.
Hinweis:
Angesichts all der oben genannten Aspekte und der in vielen Tests beobachteten Leistungsstrafen unterstützt Oracle keine gestreckten Oracle Fusion Middleware-Cluster, die eine Latenzzeit von mehr als 10 Millisekunden (RTT) zwischen den Sites überschreiten. Systeme können ohne Probleme funktionieren, aber die Transaktionszeiten werden erheblich steigen. Latenzzeiten über 10 Millisekunden (RTT) führen auch zu Problemen im Oracle Coherence-Cluster, das für Deployment und JT, Webservices oder Anwendungstimeouts verwendet wird. Dadurch eignen sich die in diesem Playbook vorgestellten Lösungen vor allem für Sites oder Regionen mit geringer Latenz dazwischen.
Wenn Sie ein Cluster mit 2 Knoten belasten, zeigt das folgende Diagramm die Gesamtperformance des Clusters, je nachdem, wo sich die Server befinden. Die Referenz (100%) ist, wenn beide Server in derselben AD wie die Datenbank ausgeführt werden.
Wenn Sie ein Cluster mit 2 Knoten belasten, zeigt das folgende Diagramm die Performance für den Server, der nicht mit der Datenbank (in der anderen AD oder in einer Remoteregion) kollokiert ist, im Vergleich zur Performance des Servers, der mit der Datenbank kollokiert ist:
Wenn Sie ein Cluster mit 2 Knoten belasten, werden in diesen Diagrammen die Anzahl der aktiven Datenquellenverbindungen (Durchschnitt) für jeden Server angezeigt. Ein Server wird immer mit der Datenbank (site1) abgelegt, und der andere Server hat andere Latenzwerte als die Datenbank (site2):
Wenn Sie einen einzelnen Server mit unterschiedlichen Datenbanklatenzen belasten, werden die folgenden Performanceergebnisse im Vergleich zu einem Server beobachtet, der sich unter mittlerer bis hoher Last in der Datenbank befindet. Die Referenz (100%) ist, wenn sich der Server in derselben AD wie die Datenbank befindet.
Wenn Sie einen einzelnen Server mit unterschiedlichen Latenzzeiten für die Datenbank belasten, sind dies die aktiven Datenquellenverbindungen unter mittlerer bis hoher Belastung:
Wenn ein einzelner Server mit unterschiedlichen Latenzzeiten für die Datenbank belastet wird, zeigt die folgende Abbildung die durchschnittliche aktive JTA-Zeit für verschiedene Latenzzeiten für die Datenbank:
Beim Vergleich der Performance eines Clusters mit beiden Servern in derselben Region wie die Datenbank (nur lokal) und einem Cluster mit beiden Servern in einer anderen Region als die Datenbank (nur Remote) werden die folgenden Performanceergebnisse beobachtet. Die Referenz (100%) ist das rein lokale Cluster.
Die folgende Abbildung zeigt die durchschnittliche JTA TX-Aktivzeit für ein Cluster, wobei beide Server in derselben Region wie die Datenbank ausgeführt werden (nur lokal) und ein Cluster beide Server in einer anderen Region als die Datenbank ausführt (nur Remote).
Startzeiten prüfen
Je nach den anfänglichen Kapazitätseinstellungen in den Datenquellen werden unterschiedliche Verzögerungen erwartet. Standardmäßig verwenden die meisten Oracle Fusion Middleware-(FMW-)Datenquellen eine anfängliche Kapazität von Null für ihren Verbindungspool. Um die Antwortzeit des Systems während des normalen Laufzeitbetriebs zu reduzieren, kann es jedoch vorteilhaft sein, die anfängliche Poolkapazität zu erhöhen. In einem gestreckten Cluster weisen die Server, die sich remote in der Datenbank befinden, jedoch beim Start eine erhöhte Latenz auf, da eine höhere anfängliche Poolkapazität verwendet wird.
Es ist eine ausgewogene Entscheidung zwischen der Optimierung der Reaktionszeiten während des normalen Betriebs und der Minimierung der Startzeit erforderlich, um die idealen anfänglichen Kapazitätseinstellungen zu bestimmen. Da die anfängliche Kapazität auf der Ebene der Datenquelle (Verbindungspool) konfiguriert wird, beeinflussen diese Einstellungen die Startzeit für alle Server im Cluster (die lokalen Server in der Datenbank und die entfernten Server in der Datenbank).
Das folgende Diagramm zeigt die Startzeiten des WebLogic-Servers bei zunehmender Latenz für die Datenbank für verschiedene Anfangsgrößenwerte in allen Datenquellen (insgesamt 11 Datenquellen):
JMS-Service-Migrationszeiten prüfen
Die Zeit für einen Service-Migrationsvorgang von Region 1 in Region 2 kann sich jedoch aufgrund der Latenz für die Datenbank erhöhen. Diese Erhöhung wird durch die Zeit verursacht, die für das Recovery der Nachrichten auf dem anderen Server aufgewendet wurde, da sie aus dem persistenten Speicher in der Datenbank in der anderen Region gelesen werden.
Das Inkrement ist höher, wenn die persistenten Speicher eine große Anzahl ausstehender Nachrichten aufweisen. Bei JMS-Nachrichten mit einer Größe von jeweils 2,7 KB zeigt das folgende Bild die Migrationszeiten des JMS-Service an, wenn einer der persistenten Speicher eine hohe Anzahl ausstehender Nachrichten (ca. 8000) aufweist und der Service von einem Server migriert, der mit der Datenbank auf einen anderen Server für unterschiedliche Latenzzeiten zwischen dem Zielserver und der Datenbank verbunden ist:
Die folgende Abbildung zeigt das Zeitinkrement für die Servicemigration (%) mit einer hohen Anzahl ausstehender Nachrichten (ca. 8000) für verschiedene Latenzzeiten zwischen dem Zielserver und der Datenbank. Die Referenz (100%) ist, wenn der Service zu einem Server migriert wird, der sich in derselben Availability-Domain (AD) wie die Datenbank befindet.
Die folgende Abbildung zeigt die Migrationszeiten für denselben Fall mit einer geringen Anzahl ausstehender Nachrichten (ca. 50) für verschiedene Latenzzeiten zwischen dem Zielserver und der Datenbank.
Die folgende Abbildung zeigt das Zeitinkrement für die JMS-Servicemigration (%) mit einer geringen Anzahl ausstehender Nachrichten (ca. 50) für verschiedene Latenzzeiten zwischen dem Zielserver und der Datenbank. Die Referenz (100%) ist, wenn der Service zu einem Server migriert wird, der sich in derselben AD wie die Datenbank befindet.
SOA-Composite-Deployment-Zeiten prüfen
Beim Deployment einer Composite Application (Bereitstellung der ersten Version oder Aktualisierung auf eine neuere Version) kann die Composite Application früher auf Servern in Region 1 als auf den Servern in Region 2 bereitgestellt werden. Sie wird jedoch erst formal aktiviert, wenn sie in allen Membern des Clusters verfügbar ist.
Die folgende Abbildung zeigt die längere Ladezeit für ein Composite auf einem Server während des Serverstarts mit einer Latenz für die Datenbank im Vergleich zur Ladezeit auf einem Server, der sich in derselben Availability-Domain (AD) wie die Datenbank befindet. Die Composite-Größe beträgt 365 KB.
Die folgende Abbildung zeigt die längere Zeit für das Deployment einer Composite Application mit den Oracle WebLogic Scripting Tool-(WLST-)Befehlen für unterschiedliche Latenzzeiten vom Server, der das Deployment in der Datenbank ausführt.
Traffic zwischen Sites prüfen
Diese Isolation ist jedoch nicht deterministisch (Beispiel: Es gibt Platz für Failover-Szenarios, in denen ein Java Message Service-(JMS-)Aufruf über die beiden Sites stattfinden könnte). Für eine typische Anwendung findet der größte Teil des Datenverkehrs zwischen den Oracle WebLogic Server-Instanzen und der Datenbank statt. Dies ist der Schlüssel zur Performance der Oracle Fusion Middleware-(FMW-)Topologie der gestreckten Cluster. Diese Abbildung zeigt den Prozentsatz des Traffics zwischen einem WebLogic-Server in Region 2 und den verschiedenen Adressen in Region 1 während eines Stresstests. Beachten Sie, dass mehr als 90% des Datenverkehrs zwischen dem Server und der Datenbank erfolgt, die sich in Region 1 befindet.
Um die Menge an Traffic pro IP zwischen den Sites zu erfassen, können Sie das iftop-Tool verwenden. Beispiel:
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900Die folgende Abbildung zeigt den Prozentsatz des Traffics zwischen einem WebLogic-Server in Region 2 und den verschiedenen Adressen in Region 1 während eines Stresstests.
