Überflutungslasttest

Die Informationen in diesem Thema beziehen sich auf die Tests, die in Testszenarien für die Messung von MST der Engine erläutert werden.

Was verursacht Floodgate-Ereignisse?

Es gibt eine Reihe von Szenarien, in denen nur wenige große Nachrichtenspitzen (auch als Überflutungsereignisse bezeichnet) von Nachrichten pro Tag im System eintreffen. Zwischen diesen Spitzen kann der Durchsatz sehr niedrig sein. Beispiele für diese Szenarien sind:

• Aktienhandel zum Beispiel bei Marktöffnung und Marktschluss

• Bankensysteme, z. B. während der Transaktionsabstimmung am Ende des Tages

  Andere Arten von Ereignissen können zu einem Backlog-Verhalten führen, das den Überflutungsereignissen ähnelt. Wenn beispielsweise eine Partner-Sendeadresse offline geht, sodass Nachrichten, die für diese Adresse bestimmt sind, erneut gesendet und/oder angehalten werden müssen, kann dies dazu führen, dass sich ein Rückstau bildet. Wenn der Partner wieder online geht, kann es eine große Anzahl an angehaltenen Nachrichten geben, die wieder aufgenommen werden müssen, was zu einer anderen Art von Floodgate-Ereignis führt. Der folgende Test des Systems veranschaulicht dieses Verhalten.

Simulieren eines Floodgate-Ereignisses

Für diesen Test wurde das System zunächst bei etwa der Hälfte des maximalen nachhaltigen Durchsatzes gesteuert, der natürlich sehr stabil war. Um ein Überflutungsereignis zu simulieren, wurde das Lastgenerierungstool so konfiguriert, dass es für eine kurze Zeit etwa 410 Nachrichten/Sek. gesendet werden sollten (identisch mit dem Overdrive-Test). Die resultierende Lastprofilmessungsmeldungen, die pro Sekunde empfangen werden, und die Tiefen des Spools werden unten angezeigt.

Lastprofil des Belastungstests für Schleusentore

Beachten Sie aus dem Diagramm, dass die Spooltabellen während des "Floodgate"-Ereignisses schnell einen Backlog aufgebaut haben. Da das Ereignis jedoch relativ kurzlebig war und die nachfolgende Empfangsrate nach dem Ereignis unter der maximalen nachhaltigen Rate lag, konnten die Bereinigungsaufträge ausgeführt werden und sich vom Ereignis erholen, ohne dass ein Systemempfangsausfall erforderlich war. Für diesen speziellen Test wurde das MessageBox-Objekt in SQL Server 2005 untergebracht; die Dauer dieses Tests von Anfang bis Ende betrug ca. 45 Minuten.

Natürlich ist jedes System anders, sodass "Ihre Ergebnisse können abweichen." Die beste Möglichkeit, um zu überprüfen, ob Sie eine Wiederherstellung durchführen können, ist das Testen mit einer repräsentativen Auslastung, bevor Sie in die Produktion gehen.

Siehe auch

Testszenarien für die Messung des MST des Motors
Verwenden des Einstellungsdashboards für BizTalk Server-Leistungsoptimierung
Overdrive Load Test
Nachhaltiger Lasttest