Freigeben über


Untersuchen von Engpässen

In diesem Thema wird ein empfohlener Prozess zum Untersuchen von Engpässen beschrieben.

Was ist die Ursache des Problems?

Die Ursache des Engpasses kann hardware- oder softwarebezogen sein. Wenn Ressourcen nicht ausgelastet sind, ist dies in der Regel ein Hinweis auf einen Engpass. Engpässe können durch Hardwarebeschränkungen, ineffiziente Softwarekonfigurationen oder beides verursacht werden.

Das Ermitteln von Engpässen ist ein inkrementeller Prozess, bei dem die Behebung eines Engpasses zur Entdeckung des nächsten führen kann. Ziel dieses Themas ist die Erläuterung geeigneter Verfahren zum Ermitteln und Verringern dieser Engpässe. Ein System kann für kurze Zeit Spitzenleistungen liefern. Bei einem dauerhaften Durchsatz kann ein System jedoch nur so schnell arbeiten wie seine langsamste Komponente.

Verwenden eines iterativen Testansatzes

Engpässe können an den Endpunkten (Ein-/Ausstieg) des Systems oder in der Mitte (Orchestrierung/Datenbank) auftreten. Nachdem der Engpass isoliert wurde, verwenden Sie einen strukturierten Ansatz, um die Quelle zu identifizieren. Nachdem der Engpass gelockert wurde, ist es wichtig, die Leistung erneut zu messen, um sicherzustellen, dass an anderer Stelle im System kein neuer Engpass entsteht.

Die Ermittlung und Behebung von Engpässen sollte iterativ erfolgen. Variieren Sie jeweils nur einen Parameter, wiederholen Sie während jedes Testlaufs genau die gleichen Schritte, und messen Sie dann die Leistung, um die Auswirkungen der einzelnen Änderung zu überprüfen. Werden mehrere Parameter gleichzeitig geändert, kann die Wirkung der Änderung möglicherweise nicht mehr eindeutig festgestellt werden.

Beispielsweise könnte das Ändern von Parameter 1 die Leistung verbessern. Das Ändern von Parameter 2 in Verbindung mit der Änderung von Parameter 1 kann jedoch nachteilige Auswirkungen haben und die Vorteile der Änderung von Parameter 1 negieren. Dies führt zu einem Netto-Null-Effekt und führt zu einem falsch negativen Effekt auf die Auswirkung des variierenden Parameters 1 und zu einem falsch positiven Effekt auf den Effekt des variierenden Parameters 2.

Testen der Konsistenz

Das Messen der Leistungsmerkmale nach dem Ändern der Einstellungen sollte durchgeführt werden, um die Auswirkungen der Änderung zu überprüfen.

  • Hardware- Verwenden Sie konsistente Hardware, da das Variieren der Hardware zu inkonsistentem Verhalten und irreführenden Ergebnissen führen kann. Sie würden beispielsweise keinen Laptop verwenden, um die Leistung einer BizTalk-Lösung zu testen.

  • Dauer des Testlaufs: Messen Sie die Leistung für einen festen Mindestzeitraum, um sicherzustellen, dass die Ergebnisse nachhaltig sind. Durch das Ausführen von Tests für längere Zeiträume wird außerdem sichergestellt, dass das System die anfängliche Warm-/Anlaufphase durchlaufen hat, in der alle Caches aufgefüllt werden, Datenbanktabellen die erwartete Anzahl erreicht haben und die Drosselung ausreichend Zeit erhält, um den Durchsatz zu regulieren, sobald vordefinierte Schwellenwerte erreicht werden. Diese Methode trägt dazu bei, den optimalen dauerhaften Durchsatz zu ermitteln.

  • Testparameter – Variieren Sie die Testparameter nicht von Testlauf zu Testlauf. Die Änderung von Zuordnungskomplexität und/oder Dokumentgrößen kann z. B. zu unterschiedlichen Ergebnissen bei Durchsatz und Wartezeit führen.

  • Sauberer Zustand: Stellen Sie nach Abschluss eines Tests sicher, dass der Status der Testumgebung sauber ist, bevor Sie den nächsten Test ausführen. Beispielsweise können verlaufsbezogene Daten in der Datenbank erstellt werden, die sich auf den Laufzeitdurchsatz auswirken. Durch das Recycling der Dienstinstanzen können zwischengespeicherte Ressourcen wie Arbeitsspeicher, Datenbankverbindungen und Threads freigegeben werden. In Ihrer Testumgebung können Sie die bts_CleanupMsgbox gespeicherte Prozedur erstellen und ausführen, wie unter Manuelles Löschen von Daten aus der MessageBox-Datenbank in einer Testumgebung (https://go.microsoft.com/fwlink/?LinkId=158064) beschrieben. Mit diesem Skript soll die BizTalk Server Testumgebung in Bezug auf das Meldungsfeld zwischen den Ausführungen in einen neuen Zustand versetzt werden. Das Skript löscht alle ausgeführten Instanzen und alle Informationen zu diesen Instanzen, einschließlich Zustand, Nachrichten und Abonnements, belässt jedoch alle Aktivierungsabonnements, sodass Sie Ihre Orchestrierungen nicht erneut eintragen oder Ports senden müssen. Beachten Sie, dass dieses Tool in Produktionssystemen nicht unterstützt wird.

  • Leistungstests und -optimierungen : Das Ziel dieser Testkategorie besteht darin, die Leistung und den Durchsatz Ihrer Anwendung zu maximieren und den maximalen nachhaltigen Durchsatz (Maximum Sustainable Throughput, MST) Ihres Systems zu ermitteln. Weitere Informationen zur Planung und Messung der maximalen nachhaltigen Leistung finden Sie unter Planning for Sustainable Performance (https://go.microsoft.com/fwlink/?LinkId=158065) and What Is Sustainable Performance? (https://go.microsoft.com/fwlink/?LinkId=132304).

    Die MST ist die höchste Last an Nachrichtendatenverkehr, die ein System unbegrenzt in einer Produktionsumgebung verarbeiten kann. Alle BizTalk-Anwendungen sollten auf Leistung und Durchsatz getestet werden, bevor sie in die Produktion gehen. Sie sollten mindestens einen repräsentativen Satz von Testfällen ausführen, die die gängigsten Verwendungsszenarien darstellen. Es wird empfohlen, dass Sie in einer separaten Umgebung, die den Merkmalen der Produktionsumgebung entspricht, anhand erwarteter Lasten und Spitzenlasten testen. In dieser Umgebung sollten alle Standarddienste des Unternehmens installiert und ausgeführt werden, z. B. Überwachungs-Agents und Antivirensoftware.

  • Außerdem wird empfohlen, neue BizTalk-Anwendungen auf derselben Hardware in der Produktion zusammen mit den anderen ausgeführten BizTalk-Anwendungen zu testen. Diese anderen BizTalk-Anwendungen belasten die BizTalk Server, die SQL Server, die Netzwerk-E/A und die Datenträger-E/A. Darüber hinaus kann eine BizTalk-Anwendung dazu führen, dass eine andere drosselt (z. B. wenn die Spooltiefe zu groß wird). Alle BizTalk-Anwendungen sollten vor dem Produktionsbetrieb auf Leistung/Belastung getestet werden. Darüber hinaus sollten Sie bestimmen, wie lange es dauert, bis das System nach Spitzenlasten wiederhergestellt wird. Wenn das System nach einer Spitzenlast nicht vollständig wiederhergestellt wird, bevor die nächste Spitzenlast auftritt, liegt ein Problem vor. Das System wird immer weiter zurück und kann nie vollständig wiederhergestellt werden.

Erwartungen: Durchsatz im Vergleich zu Latenz

Sie können eine bestimmte Menge an Durchsatz und/oder Latenz vom bereitgestellten System erwarten. Der Versuch, einen hohen Durchsatz und eine geringe Latenz zu erreichen, stellt gleichzeitig entgegengesetzte Anforderungen an das System. Sie können einen optimalen Durchsatz mit angemessener Latenz erwarten. Wenn sich der Durchsatz verbessert, nimmt die Belastung (z. B. höherer CPU-Verbrauch, höherer Datenträger-E/A-Konflikt, Arbeitsspeicherauslastung und größere Sperrkonflikte) auf dem System zu. Diese Situation kann sich negativ auf die Latenz auswirken. Um die optimale Kapazität eines Systems zu ermitteln, empfiehlt es sich, Engpässe zu identifizieren und zu minimieren.

Abgeschlossene Instanzen, die sich in der Datenbank befinden, können zu Engpässen führen. Wenn Engpässe auftreten, kann die Leistung beeinträchtigt werden. Wenn dem System genügend Zeit zur Entleerung gegeben wird, kann das Problem behoben werden. Es ist wichtig, die Ursache für die Backlogerstellung zu ermitteln und das Problem zu beheben.

Um die Ursache des Backlogs zu ermitteln, können Sie Verlaufsdaten analysieren und Leistungsindikatoren überwachen (um Nutzungsmuster zu ermitteln und die Quelle des Backlogs zu diagnostizieren). In der Regel können Backlogs auftreten, wenn große Datenmengen nachts in Batchverarbeitung verarbeitet werden. Es kann hilfreich sein, die Kapazität des Systems und seine Fähigkeit zur Wiederherstellung aus einem Backlog zu ermitteln. Diese Informationen können Ihnen helfen, die Hardwareanforderungen für die Behandlung von Overdrive-Szenarien und den Pufferraum zu schätzen, der innerhalb eines Systems zur Bewältigung unvorhergesehener Durchsatzspitzen untergebracht werden soll.

Die Überwachung von Leistungsindikatoren kann dazu beitragen, potenzielle Engpässe zu beseitigen, die zur Laufzeit auftreten können. Wenn wir jedoch vermuten, dass der Ursache eines CPU- oder Arbeitsspeicherengpasses eine der benutzerdefinierten Komponenten ist, aus denen die Lösung besteht, wird dringend empfohlen, profilerstellungstools wie Visual Studio Profiler oder ANTS Performance Profiler während eines Leistungstests zu verwenden, um die Klasse, die das Problem verursacht, mit Sicherheit einzugrenzen und zu individuzieren. Offensichtlich beeinträchtigt die Profilerstellung für eine Anwendung die Leistung. Daher sollten sich diese Tests auf die Individuduzierung der Komponenten konzentrieren, die Arbeitsspeicherverbrauch, CPU-Auslastung oder Latenz verursachen, und zahlen, die während dieser Tests gesammelt wurden, sollten verworfen werden.

Die Optimierung des Systems für einen optimalen nachhaltigen Durchsatz erfordert ein tiefes Verständnis der bereitgestellten Anwendung, der Stärken und Schwächen des Systems sowie der Nutzungsmuster des jeweiligen Szenarios. Nur bei gründlichen Tests einer Topologie, die weitgehend der in der Produktion eingesetzten entspricht, ist es möglich, Engpässe zu ermitteln und den optimalen dauerhaften Durchsatz mit Sicherheit vorherzusagen. Beim Ausführen von Auslastungs- und Belastungstests für einen bestimmten Anwendungsfall ist es wichtig, einzelne Artefakte (Empfangsspeicherorte, Sendeports, Orchestrierungen) in separaten Hostinstanzen zu isolieren und die richtigen Leistungsindikatoren im Leistungsmonitortool festzulegen, um die Ursache eines Engpasses einzugrenzen.

Andere Themen in diesem Abschnitt führen Sie durch den Prozess der Definition dieser Topologie und bieten Anleitungen zur Verkürzung und Vermeidung von Engpässen.

Skalierung

Engpässe können in verschiedenen Phasen einer bereitgestellten Topologie auftreten. Einige Engpässe können entweder durch hoch- oder horizontales Hochskalieren der Umgebung behoben werden. Das Hochskalieren ist der Prozess des Upgrades des vorhandenen Computers. Sie können beispielsweise einen BizTalk Server Computer von einem Computer mit vier Prozessoren auf einen Computer mit acht Prozessoren aktualisieren und die vorhandenen CPUs ersetzen und mehr RAM hinzufügen. Auf diese Weise können Sie ressourcenintensive Aufgaben wie die Dokumentanalyse und -zuordnung beschleunigen. Horizontales Hochskalieren ist der Prozess zum Hinzufügen von Servern zu Ihrer Bereitstellung. Die Entscheidung, hoch- oder herunterzuskalieren, hängt von der Art des Engpasses und der zu konfigurierenden Anwendung ab. Eine Anwendung muss von Grund auf erstellt werden, um die Vorteile des Hoch- oder Hochskalierens nutzen zu können. In der folgenden Anleitung wird erläutert, wie Sie Hardwarebereitstellungstopologien basierend auf aufgetretenen Engpässen ändern.

Hochskalieren bedeutet, dass eine BizTalk-Lösung auf aktualisierter Hardware ausgeführt wird (z. B. hinzufügen von CPU und Arbeitsspeicher). Sie sollten sich das Hochskalieren ansehen, wenn 1) das Horizontale Hochskalieren zu teuer ist oder 2) das Herunterskalieren keinen Engpass löst. Beispielsweise können Sie den Zeitaufwand für die Transformation und Verarbeitung einer großen Nachricht erheblich reduzieren, wenn Sie die Aufgabe auf einem schnelleren Computer ausführen.

Das horizontale Hochskalieren der Anwendungsplattform besteht aus dem Hinzufügen von BizTalk-Knoten zur BizTalk Server-Gruppe und deren Verwendung zum Ausführen eines oder mehrerer Teile der Lösung. Sie sollten sich die Horizontale Skalierung ansehen, wenn Sie 1) Senden, Empfangen, Verarbeiten, Nachverfolgen von Hosts isolieren müssen, oder 2) wenn arbeitsspeicher-, E/A- oder Netzwerk-E/A-Ressourcen für einen einzelnen Server maximal ausgegrenzt sind. Die Last kann auf mehrere Server verteilt werden. Das Hinzufügen neuer Knoten zur BizTalk Server-Gruppe kann jedoch den Sperrkonflikt in der MessageBox-Datenbank erhöhen.

Sollten Sie also hoch- oder horizontal hochskalieren? Das Hochskalieren Ihrer Plattform kann die Latenz einer BizTalk-Lösung verringern, da einzelne Aufgaben (z. B. Nachrichtenzuordnung) schneller ausgeführt werden. Durch horizontales Hochskalieren können Sie die maximale nachhaltige Durchlaufnutzung und die Skalierbarkeit Ihrer BizTalk-Lösung verbessern, da sie es Ihnen ermöglicht, die Workload auf mehrere Computer zu verteilen.

Weitere Informationen

Suchen und Beseitigen von Engpässen