Teilen über

Was bedeutet nachhaltige Leistung?

  • Artikel

Beim Planen und Einschätzen von Systemnachhaltigkeit ist es wichtig, Nachhaltigkeit in langfristigem Maßstab anzustreben. Die wichtigsten Aspekte dabei sind:

  • Ladeprofile und Leistungsziele: Sie können nicht zu viele Details haben, wenn es um Ladeprofile und Leistungsziele geht. Test- und Bereitschaftszertifizierung basieren darauf, wie diese Lasten langfristig verarbeitet werden können.

  • Andere Aktivitäten und Prozesse, die um Serverressourcen konkurrieren: Es geht nicht nur um das Laden von Nachrichten. Auf den Servern werden noch andere Aktivitäten und Prozesse ausgeführt, die sich auf die Leistung auswirken, wie die Datenbankverwaltung und MessageBox-Abfragen.

  • Geplante und ungeplante Systemausfälle und Ausfallzeiten: Floodgate-Ereignisse und Nachrichtenbacklog können das effektive Ladeprofil ändern.

    Wenn Sie nachhaltige Systeme planen und zum Zertifizieren testen möchten, müssen Sie diese Faktoren unbedingt berücksichtigen und in Ihre Planung einbeziehen.

Ist die Leistung Ihres Systems nachhaltig?

Wenn wir über die Leistung für BizTalk Server sprechen, definieren wir die maximale nachhaltige Leistung wie folgt:

  • Die höchste Last an Nachrichtenverkehr, die ein System in einer Produktionsumgebung auf unbegrenzte Zeit verarbeiten kann.

    Das hört sich eigentlich ganz einfach an. Sie müssen jedoch viele Faktoren berücksichtigen, wenn Sie abschätzen möchten, ob eine Lösung (auf der jeweiligen Hardwareplattform) die Lasten verarbeiten kann, die in einer Produktionsumgebung tagein, tagaus anfallen.

    Bevor Sie also Ihre Lösung in die Produktionsumgebung umsetzen, ziehen Sie die nachfolgend beschriebenen Faktoren in Erwägung. Auf diese Weise können Sie besser bewerten, ob die Lösung die höchste Last an Nachrichtenverkehr auf unbegrenzte Zeit verarbeiten kann:

  • Gewünschte Leistungsziele und Durchsatz/Wartezeit-Profile.

  • Andere Prozesse, die auf derselben Hardware ausgeführt werden, wie:

    • Normale Überwachung und Fehlerbehebung

    • Vorgänge zur Datenbankwartung, wie Protokollversand, Sicherung, Löschvorgänge, Indexverwaltung und Statistikaktualisierungen

    • Andere Anwendungen

  • Geplante und ungeplante Systemausfälle, wie:

    • Ausfälle von Partnersites, wodurch das Senden oder Empfangen von Nachrichten blockiert wird

    • Ausfallzeiten während der normalen Systemwartung

Ermitteln von Leistungszielen

Bevor Sie Ihre Lösung hinsichtlich ihrer Nachhaltigkeit bewerten können, müssen Sie über eine genaue Einschätzung der erwarteten Produktionslasten verfügen. Ohne ein genau durchdachtes Ziel können Sie die Einsetzbarkeit nicht bewerten. Eine detaillierte Auflistung der Leistungsziele ist wichtig, da Systemtests und Zertifizierungen auf diesen Informationen basieren. Ihre Leistungsziele sollten die folgenden Elemente enthalten:

  • Eine Kurve, die den Verlauf der Leistung in Abhängigkeit von der Zeit definiert. Diese Funktionen können sehr einfach aber auch sehr kompliziert sein.

  • Eine mit der Leistungsfunktion verknüpfte Leistungsanforderung.

  • Eine Verteilung von Dateigrößen und -typen.

Beispiel 1

  • Jeden Tag erhöht sich die Nachrichtenmenge von 0 Nachr/Sek um 8.00 Uhr morgens auf bis zu 80 Nachr/Sek um 12.00 Uhr mittags und geht dann wieder auf 0 Nachr/Sek um 21.00 Uhr abends zurück, etwa in der Form einer Glockenkurve.

  • Das System hat keine besondere Wartezeitanforderung für die einzelnen Nachrichten. Es muss jedoch in der Lage sein, diese Last zu verarbeiten, inklusive der gesamten Nachrichtenlast des Vortages (z. B. im Falle eines Systemausfalls für 24 Stunden), ohne in einen Rückstand zu geraten.

  • Es gibt drei Dokumenttypen: Sales Basket, Back Order und Stock Request. "Sales Basket"-Dokumente sind zwischen 2 und 10 KB groß und machen zu jedem beliebigen Zeitpunkt 75 % der Nachrichtenmenge aus. "Back Order"- und "Stock Request"-Dokumente sind immer etwa 1 KB groß und machen die verbleibenden 10 % und 15 % der Nachrichtenmenge aus, ebenfalls zu jedem beliebigen Zeitpunkt.

Beispiel 2

  • Jeden Tag um Mitternacht gehen 500.000 Nachrichten zum Verarbeiten ein.

  • Alle Nachrichten im Stapel müssen innerhalb von 8 Stunden vollständig verarbeitet werden.

  • Alle Nachrichten sind vom gleichen Typ und hinsichtlich ihrer Größe gleichmäßig zwischen 10 und 50 KB verteilt. Zusätzlich enthält der Stapel immer 10 Nachrichten vom Typ "Katalog" mit jeweils 10 MB, die zum Verarbeiten in einzelne Katalogeinträge unterteilt werden müssen.

Beispiel 3

  • Jeden Morgen um 8.00 Uhr melden sich 4.000 Kundendienstmitarbeiter beim interaktiven System an und führen bis zum Geschäftsschluss um 17.00 Uhr durchschnittlich 4 Anfragen pro Mitarbeiter und Minute durch, und das sieben Tage die Woche.

  • Für alle Anfragen müssen in weniger als 2 Sekunden Ergebnisse zurückgegeben werden.

  • Alle Anfragen sind vom gleichen Typ und hinsichtlich ihrer Größe gleichmäßig zwischen 500 und 1.000 KB verteilt.

Eine mit der Leistungsfunktion verknüpfte Leistungsanforderung

Für die vorangegangenen Beispiele würde dies bedeuten:

  • Beispiel 1 (Fortsetzung): Das System hat keine spezifische Latenzanforderung für jede Nachricht, aber es muss in der Lage sein, diese Last sowie die gesamte Nachrichtenlast des Vortages (z. B. bei einem 24-Stunden-Systemausfall) zu verarbeiten, ohne zurückzukommen.

  • Beispiel 2 (Fortsetzung): Alle Nachrichten im Batch müssen in 8 Stunden verarbeitet werden.

  • Beispiel 3 (Fortsetzung): Alle Abfragen müssen Ergebnisse in weniger als 2 Sekunden zurückgeben.

Eine Verteilung von Dateigrößen und -typen

  • Beispiel 1 (Fortsetzung): Es gibt drei Dokumenttypen: Verkaufskorb, Back Order und Stock Request. "Sales Basket"-Dokumente sind zwischen 2 und 10 KB groß und machen zu jedem beliebigen Zeitpunkt 75 % der Nachrichtenmenge aus. "Back Order"- und "Stock Request"-Dokumente sind immer etwa 1 KB groß und machen die verbleibenden 10 % und 15 % der Nachrichtenmenge aus, ebenfalls zu jedem beliebigen Zeitpunkt.

  • Beispiel 2 (Fortsetzung): Alle Nachrichten haben denselben Typ und sind gleichmäßig auf 10 bis 50 KB verteilt, einschließlich. Zusätzlich enthält der Stapel immer 10 Nachrichten vom Typ "Katalog" mit jeweils 10 MB, die zum Verarbeiten in einzelne Katalogeinträge unterteilt werden müssen.

  • Beispiel 3 (Fortsetzung): Alle Anfragen sind vom gleichen Typ und gleichmäßig zwischen 500 und 1.000 Byte verteilt, einschließlich.

Einkalkulieren anderer Prozesse

Neben den Profilen der Lasten, die direkt durch die BizTalk-Engine laufen, sind immer noch weitere Prozesse vorhanden, die auf derselben Hardware Ressourcen beanspruchen. Diese anderen Prozesse reduzieren die nachhaltige Gesamtleistung des Systems. Die Wartung von Datenbanken ist das wohl häufigste Beispiel für diese Art von Prozessen.

Bei jeder kleinen oder großen Datenbank fallen regelmäßig Wartungsarbeiten wie Protokollversand, Sicherung, Archivierung und Löschvorgänge an. Die Überwachung und Fehlerbehebung sind weitere Beispiele für Vorgänge, die Sie beim Definieren und Zertifizieren von nachhaltiger Leistung berücksichtigen müssen. Das Abfragen der MessageBox (z. B. über die Gruppenhubseite der Verwaltungskonsole), um zu ermitteln, wie viele Nachrichten eines bestimmten Typs in den letzten 24 Stunden angehalten wurden, verbraucht beispielsweise Ressourcen von SQL Server, die anderenfalls zum Verarbeiten von Nachrichten zur Verfügung stehen würden.

Im Folgenden finden Sie eine Liste der Aktivitäten, die in der Regel die meisten Auswirkungen auf die Gesamt-Nachhaltigkeit in BizTalk Server haben:

  • Protokollversand und -sicherung. Im Rahmen der meisten Notfallwiederherstellungspläne mit SQL Server müssen Sie den Protokollversand und die Sicherung für alle BizTalk Server Gruppendatenbanken in regelmäßigen Abständen durchführen. Weitere Informationen finden Sie unter Sichern und Wiederherstellen BizTalk Server Datenbanken. Siehe auch Protokollversand.

  • Archivieren und Bereinigen von Nachverfolgungsdaten. Zusätzlich zum gesamten Protokollversand- und Sicherungsplan verfügt die BizTalk-Nachverfolgungsdatenbank (BizTalkDTADb) über eigene Archivierungs- und Bereinigungsregime. Weitere Informationen finden Sie unter Archivieren und Bereinigen der BizTalk-Nachverfolgungsdatenbank. Die Geschwindigkeit, mit der Daten archiviert und aus der BizTalk-Überwachungsdatenbank gelöscht werden, ist besonders wichtig, da Archivierungs- und Löschvorgänge in der BizTalk-Überwachungsdatenbank häufig Engpässe verursachen, wenn die Überwachung aktiviert ist.

  • Systemabfragen. Die Verwendung von APIs oder der Benutzeroberfläche der BizTalk Server-Verwaltungskonsole zum Ausführen verschiedener Arten von Abfragen für das System wirkt sich auf die nachhaltige Leistung aus.

  • MessageBox-Wartung. Es gibt eine Reihe von SQL-Aufträgen, die Teil der Kernfunktionalität von BizTalk Server sind, die die MessageBox-Datenbank verwalten, indem Nachrichten und Instanzen, die die Verarbeitung abgeschlossen haben, bereinigen. Als Bestandteil der Kern-Engine stellt die Geschwindigkeit, mit der diese Aufgaben durchgeführt werden können, einen der wichtigsten Faktoren beim Beurteilen der Nachhaltigkeit dar. Weitere Informationen zu diesen Aufträgen und ihrer Rolle finden Sie unter Verwalten von BizTalk Server1.

  • Projektmappenbereitstellungsaktivitäten. Beim Bereitstellen, Binden und Starten neuer Anwendungen oder neuer Versionen von vorhandenen Anwendungen wird in BizTalk zusätzliche Last erzeugt, beispielsweise durch die Erstellung neuer Abonnements in den MessageBox-Datenbanken. Nachdem die Anwendungen bereitgestellt sind, beanspruchen die von ihnen verarbeiteten Nachrichten Ressourcen und wirken sich dadurch auf die Leistung vorhandener Anwendungen aus.

    Für jeden dieser Bereiche müssen Sie fragen: Was ist Ihre Empfehlung, um die Auswirkungen dieser Aktivitäten zu minimieren? Könnten sie beispielsweise zur Ausführung um 3.00 Uhr morgens geplant werden?

Berücksichtigung geplanter und ungeplanter Systemausfälle

Die Auswirkungen von Ausfällen auf die Systemleistung hängen direkt von dem System ab, auf dem der Ausfall auftritt. Die folgenden Konsequenzen treten jedoch am häufigsten auf:

  • Floodgate-Ereignisse. Wenn ein System über einen längeren Zeitraum hinweg ausfällt, können sich Nachrichten ansammeln und dann alle gleichzeitig zur Verarbeitung eintreffen, sobald das System wieder in Betrieb genommen wird. Wenn beispielsweise eine unter BizTalk ausgeführte Anwendung eine Nachricht über MSMQ empfängt und diese Anwendung einige Zeit außer Betrieb ist, sammeln sich in der Warteschlange Nachrichten an, die darauf warten, abgerufen zu werden. Wird die Anwendung wieder gestartet, führt dies zu dem Effekt, dass eine große Anzahl an Nachrichten gleichzeitig eintrifft.

  • Nachrichtenbacklog. Wenn Systeme ausfallen, an die Nachrichten gesendet werden, gibt es meist eine Wiederholungsschleife, die zusätzliche Ressourcen beansprucht. Wenn die Wiederholungsschleife überfüllt ist, werden die Nachrichten normalerweise angehalten. Wenn die ausgefallenen Systeme wieder gestartet werden, kommt es zu einer Art Datenüberflutung, bei der große Mengen an Nachrichten fortgesetzt und/oder erfolgreich versendet werden können.

    Beim Entwerfen und Zertifizieren eines Systems müssen geplante Ausfallzeiten wie regelmäßige Systemwartungen berücksichtigt werden. Es sollte jedoch auch eine Analyse aller möglichen ungeplanten Ausfallzeiten und deren Auswirkungen durchgeführt werden.

    Identifizieren Sie möglichst alle Ausfälle, die auftreten können, stufen Sie sie nach Risiko ein (d. h. geschätzte Wahrscheinlichkeit mal Schweregrad), und schätzen Sie Dauer und Auswirkungen (z. B. Datenüberflutungen, Menge der angehaltenen Nachrichten, Rückstand usw.) der mit einem höheren Risiko behafteten Ausfallzeiten ein, um einen Wert für die benötigte Systemkapazität im Falle solcher Ausfälle zu erhalten. Jedes Speicher-und-Vorwärts-, Messaging-basierte asynchrone System, wie z. B. BizTalk Server, sollte entworfen werden, um "Headroom" ausreichend zu verarbeiten, um geplante und ungeplante Ausfälle zu bewältigen.

Weitere Informationen

Persistenz und Beständigkeit der Engine
Empfehlungen für die einzelnen Phasen der Projektplanung
Messen des maximal tragbaren Engine-Durchsatzes
Messen des maximalen dauerhaften Überwachungsdurchsatzes
Skalieren Ihrer Lösungen
Erkennen von Leistungsengpässen
Engine-Leistung und -kapazität