Teilen über


Lasttest für Datenüberflutung

Die Informationen in diesem Thema beziehen sich auf die Tests, die unter Testszenarien zum Messen der MST der Engine erläutert werden.

Wodurch werden Datenüberflutungen verursacht?

Es gibt eine Reihe von Szenarien, in denen täglich nur wenige große Spitzen (auch als Flutungsereignisse bezeichnet) von Nachrichten im System eintreffen. Zwischen diesen Spitzen kann der Durchsatz sehr gering sein. Beispiele für solche Szenarien sind:

  • Aktienhandel, beispielsweise bei der Öffnung und Schließung der Märkte

  • Banksysteme, beispielsweise bei der Abstimmung von Transaktionen zum Tagesabschluss

    Andere Ereignisse können Rückstände verursachen, die Datenüberflutungen ähneln. Wenn beispielsweise eine Partnersendeadresse offline geschaltet wird, sodass die dafür bestimmten Nachrichten wiederholt gesendet und/oder angehalten werden müssen, kann sich hierdurch ein Rückstand aufbauen. Wird der Partner wieder online geschaltet, kann sich eine große Zahl angehaltener Nachrichten angesammelt haben, die erneut gesendet werden müssen, wodurch es zu einer Datenüberflutung anderer Art kommen kann. Der folgende Test des Systems veranschaulicht dieses Verhalten.

Simulieren einer Datenüberflutung

Für diesen Test wurde das System anfangs mit der Hälfte des maximal tragbaren Durchsatzes betrieben, was eine äußerst stabile Situation darstellt. Dann wurde das Lastgenerierungstool zur Simulation einer Datenüberflutung so konfiguriert, dass über einen kurzen Zeitraum etwa 410 Nachrichten pro Sekunde gesendet wurden (wie beim Überlasttest). Das sich ergebende Lastprofil, das die pro Sekunde eingegangenen Nachrichten und die Spooltiefe misst, wird unten angezeigt.

Lastprofil des Lasttests für die Datenüberflutung

Anzeige der BTS06_Floodgate_Load für die Schleusenlast im Leistungsmonitor

Aus dem Diagramm wird ersichtlich, dass sich in den Spooltabellen während der Datenüberflutung in kurzer Zeit ein Rückstand aufgebaut hat. Da das Ereignis jedoch nur kurzzeitig auftrat und die Empfangsrate nach dem Ereignis unterhalb der maximal tragbaren Rate lag, konnten die Cleanupaufträge ausgeführt werden, ohne dass es zu einem Ausfall des Systemempfangs kam. Für diesen speziellen Test wurde MessageBox auf SQL Server 2005 untergebracht. Die Testdauer betrug insgesamt etwa 45 Minuten.

Da es natürlich Unterschiede zwischen Systemen gibt, variiert auch die "Laufzeit". Um zu überprüfen, ob eine Wiederherstellung möglich ist, führen Sie am besten vor der Produktionsphase Tests mit einer repräsentativen Last durch.

Weitere Informationen

Testszenarios zum Messen des maximalen dauerhaften Durchsatzes der Engine
Verwenden des Dashboards für Einstellungen zur Leistungsoptimierung bei BizTalk Server
Überlasttest
Dauerlasttest