Phase 1: Festlegen des Umfangs der Bewertung
In diesem Thema werden die Aspekte der Bereichsphase einer BizTalk Server Leistungsbewertung beschrieben.
Ein häufiger Fehler bei der Durchführung einer Leistungsbewertung besteht darin, den Umfang der Leistungsbewertung zu unterschätzen. Wenn im Voraus nicht genügend Ressourcen und Zeit zugeordnet sind, kann das für die Leistungsbewertung zuständige Team nicht alle Aufgaben ausführen, die zum Erstellen und Testen einer komplexen produktionsähnlichen Umgebung erforderlich sind. Das Team, das an der Leistungsbewertung arbeitet, sollte seine Kämpfe sorgfältig auswählen. Die meisten Leistungsbewertungen werden innerhalb eines sehr begrenzten Zeitrahmens durchgeführt, sodass das Team ein oder zwei, höchstens drei, wichtige Leistungsziele identifizieren und sich darauf konzentrieren sollte. Die zu testende Anwendung sollte speziell entwickelt werden, um sich auf die ermittelten Leistungsziele zu konzentrieren und alle anderen Technologievariablen so weit wie möglich zu berücksichtigen. In diesem Thema werden die Aspekte der Bereichsphase einer BizTalk Server Leistungsbewertung beschrieben.
Überlegungen vor Beginn der Leistungsbewertung
Die folgenden Faktoren sollten berücksichtigt werden, bevor andere Arbeiten für eine Leistungsbewertung durchgeführt werden. Diese Faktoren helfen bei der Entscheidung über die allgemeine Richtung der Bereichsphase und sind ein guter Ausgangspunkt für eine Leistungsbewertung.
Laden von Nachrichten
Es ist wichtig, von Anfang an zu überlegen, wie Sie die Nachrichtenlast replizieren, die tatsächlich über das Produktionssystem erfolgt. Wenn bei instance in der Produktion 20 Prozent der Nachrichten <20 KB groß sind, 50 Prozent 100 KB groß sind <und die verbleibenden 30 Prozent bis zu 1 MB groß sein können, ist es wichtig, dass dies im Lab repliziert wird.
Entwickeln sie ein kurzes Detail der zu testenden Szenarien.
Nachdem Sie die Testfälle identifiziert haben, die getestet werden sollen, ist es wichtig, die Hauptkomponenten zu identifizieren, die daran beteiligt sind. Dies umfasst sowohl BizTalk Server Komponenten (z. B. Messaging und Orchestrierungen) als auch andere Komponenten, einschließlich Drittanbietertechnologien wie MQSeries oder SAP. Es ist sehr wichtig, dass Sie all diese von Anfang an kennen, da es Ihnen hilft, die Komplexität des Labs zu messen und es Ihnen ermöglicht, die während des Engagements erforderlichen technischen Fähigkeiten zu planen.
Identifizieren, welche Adapter verwendet werden sollen
Es ist von entscheidender Bedeutung, dass das Leistungsbewertungslabor die tatsächlichen Adapter verwendet, die in der Produktionsumgebung verwendet werden. Wenn sie die tatsächlichen Adapter nicht verwenden, die in der Produktion verwendet werden, führt dies zu Problemen, da die Leistung verschiedener Adapter erheblich variiert. Für instance ist der Dateiadapter einer der schnellsten BizTalk Server Adapter, aber es fehlen einige der Features, die für einige Systeme erforderlich sind. Insbesondere der Dateiadapter bietet keine Unterstützung für Transaktionen. Die Transaktionsunterstützung bietet die Möglichkeit, Nachrichten zu lesen und in die MessageBox-Datenbank zu schreiben, alles im Kontext einer MSDTC-Transaktion. Die Transaktionsunterstützung verursacht Mehraufwand. Daher wäre die Verwendung des Dateiadapters zum Simulieren eines Produktionsszenarios, das Transaktionsunterstützung erfordert, kein praktikabler Vergleich. In diesem Szenario sind die Leistungsergebnisse im Wesentlichen ungültig, da sie sehr unwahrscheinlich sind, dass sie die tatsächliche Leistung des Produktionssystems widerspiegeln.
Geschätzter Zeitaufwand für die Leistungsbewertung
Verwenden Sie die folgenden Richtlinien, um die für die Leistungsbewertung erforderliche Zeit zu schätzen:
Planen Sie zwei Wochen Vorbereitungszeit für das Einrichten der Testumgebung ein. Eine Woche wird verwendet, um die erforderliche Infrastruktur und Softwarekomponenten zu erstellen und Softwareupdates anzuwenden. Die zweite Woche wird der Einrichtung der spezifischen Umgebung gewidmet, die die BizTalk Server Produktionsumgebung dupliziert.
Weisen Sie eine zusätzliche Woche für jeden Testfall zu, der während der Leistungsbewertung analysiert wird.
Ordnen Sie am Ende der tatsächlichen Leistungsbewertung eine Woche zu, um die Ergebnisse der Leistungsbewertung zu dokumentieren.
Bei einer typischen Leistungsbewertung mit zwei Testfällen würde die geschätzte Zeit zum Abschließen der Bewertung also wie folgt lauten:
(zwei Wochen Vorbereitungszeit) + (zwei Wochen für die tatsächliche Leistungsbewertung) + (eine Woche zum Dokumentieren der Ergebnisse) = insgesamt fünf Wochen.
Dokumentieren der Leistungsbewertung
Im Rahmen der Eingrenzung der Leistungsbewertung sollten die Details der Bewertung in einer Engagementzusammenfassung dokumentiert werden. In diesem Dokument sollten Ziele und Ziele, Beteiligte und Meilensteine für die Leistungsbewertung klar definiert werden. Dieses Dokument dient als Roadmap für die Leistungsbewertung, trägt dazu bei, dass sich alle Beteiligten auf die Details des Engagements einigen und sicherstellen, dass die Leistungsbewertung auf dem richtigen Weg bleibt. Dieses Dokument sollte während der gesamten Leistungsbewertung aktualisiert werden und eine Zusammenfassung der Ergebnisse nach Abschluss der Leistungsbewertung enthalten.
Ziele
Sorgfältige Definition von Durchsatz- und Latenzzielen : Welche Leistungskriterien versuchen Sie zu maximieren? In der Regel steht ein oder mehrere der folgenden Leistungskennzahlen im Mittelpunkt einer BizTalk Server Leistungsbewertung.
Durchsatz : Wird in der Regel als Anzahl von Nachrichten pro Zeiteinheit gemessen, die über ein bestimmtes Zeitintervall verarbeitet werden können. Beispielsweise kann ein Durchsatzziel als die Möglichkeit definiert werden, 100 Nachrichten pro Sekunde für einen Zeitraum von 3 Stunden zu verarbeiten.
Latenz : In der Regel definiert als Prozentsatz aller Nachrichten, die innerhalb eines bestimmten Zeitintervalls End-to-End verarbeitet werden können, z. B.:
95 Prozent aller Nachrichten sollten innerhalb von zwei Sekunden end-to-End verarbeitet werden.
100 Prozent aller Nachrichten sollten innerhalb von vier Sekunden end-to-End verarbeitet werden.
Spitzenlasten
Zeit zum Abschließen eines Batches vonX
Schleusenwiederherstellungsszenarien
Allgemeine Architektur einschließlich Hardware und Software
Die Leistungsziele sollten in Bezug auf "Erreichen der höchstmöglichen X-Hardware - und Softwareeinschränkungen" gemessen werden. Legen Sie fest, wie das Ziel im Voraus gemessen wird. Beispiel: "Maximaler nachhaltiger Durchsatz von X End-to-End, gemessen am Zähler 'XLang/s\orchestrations completed/second'".
Hinweis
In den obigen Beispielen ist X platzhalter für die Einheit, die im Mittelpunkt der Leistungsbewertung steht. X kann Orchestrierungen, Nachrichten oder andere Leistungsmetriken darstellen, die für die BizTalk-Lösung relevant sind.
Ist die gewünschte Leistung erreichbar?
Bei der Bewertung von Leistungsüberlegungen sollten Sie zunächst ermitteln, ob die verfügbaren Hardwareressourcen ausreichen, um Ihre Leistungsziele zu erreichen. In einigen Fällen ist die gewünschte Leistung ohne zusätzliche Investitionen in Hardware einfach nicht möglich. Es gibt keine Magische Formel, die verwendet werden kann, um zu bestimmen, welche Leistung bei einer bestimmten Hardwarekonfiguration möglich ist oder nicht, da viele Faktoren die Leistung der Lösung beeinflussen, einschließlich der Komplexität der Orchestrierungen, des verwendeten benutzerdefinierten Codes, der Häufigkeit, wie Nachrichten in der MessageBox-Datenbank beibehalten werden, und Einschränkungen externer Systeme. Die folgende Tabelle enthält eine Zusammenfassung der Hardware, die zum Erreichen bestimmter Leistungsziele für bestimmte Szenarien verwendet wird.
Hinweis
Die folgenden Informationen dienen nur zur Anleitung. Die Anforderungen der verschiedenen BizTalk Server Lösung variieren stark, sodass die Werte in dieser Tabelle bei der Schätzung der erforderlichen Hardwareressourcen als grobe "Faustregel" verwendet werden sollten.
Hardwarebeispielszenarien
| Art der Verarbeitung | BizTalk Server Computer | SQL Server Computer | Erreichter Durchsatz | Hinweise |
|---|---|---|---|---|
| Orchestrierung, verfügbar gemacht als Webdienst, MQSeries-Adapter | - 6 Computer BizTalk Server 2010 – Auf jedem Server werden zwei 3-GHZ-Dual-Core-Prozessoren ausgeführt. – Windows Server 2008 R2, 8 GB Arbeitsspeicher |
- 3 SQL Server 2008 R2-Computer - Jeder Server mit vier 3-GHZ-Dual-Core-Prozessoren – 64-Bit, 16 GB Arbeitsspeicher – Einzelne MessageBox-Datenbank |
95 Orchestrierungen pro Sekunde | - Durchschnittliche Latenz 1,11 s - 99 % verarbeitete Nachrichten mit <einer Latenz von 2 Sekunden |
| Nachrichten | 6 Computer BizTalk Server 2010 | 3 SQL Server R2-Computer 2008 | Der spitzen Durchsatz, der über einen Zeitraum von 2 Stunden erreicht wurde, betrug 277 Nachrichten pro Sekunde. | Vor der Optimierung der Lösung lag der Spitzendurchsatz bei 125 Nachrichten pro Sekunde. |
| Szenario mit geringer Latenz unter Verwendung von Orchestrierungen und Webdiensten | Ein Dual-Prozessor BizTalk Server 2010-Computer | Ein Quad-Prozessor SQL Server 2008 R2-Computer | 60 Orchestrierungen pro Sekunde | < Latenzzeit von 350 Millisekunden erreicht |
| Szenario mit geringer Latenz unter Verwendung von Orchestrierungen | 23 Quad-Prozessor BizTalk Server 2010-Computer | - 3 SQL Server 2008 R2-Computer – Eine MessageBox-Datenbank mit 16 CPU-master – Zwei sekundäre MessageBox-Datenbankcomputer mit 8 CPU |
1156 Orchestrierungen pro Sekunde | Im Januar 2010 war die höchste nachhaltige Leistung BizTalk Server laufenden Orchestrierungen |
Nachdem die verfügbare Hardwareinfrastruktur als ausreichend eingestuft wurde, um die gewünschte Leistung zu erzielen, sollten Sie beim Eingrenzen einer BizTalk Server Leistungsbewertung Folgendes berücksichtigen:
Welche Adapter und/oder Accelerators sind erforderlich?
Welche Anforderungen gelten für die Implementierung von Orchestrierungen in der Lösung?
Anforderungen an den Dokumentdurchsatz: Was sind die maximalen Anforderungen an den nachhaltigen Durchsatz für die Lösung?
Latenzanforderungen: Wie reaktionsfähig muss die Lösung für Szenarien mit Anfragen und Antworten sein?
Wie gut kann die Lösung nach Zeiten mit hoher Dokumentlast wiederhergestellt werden?
Welche Hochverfügbarkeitsanforderungen gelten für die Lösung?
Was sind die Anforderungen an die Dokumentnachverfolgung der Lösung?
Wie sind die Leistungsmerkmale von abhängigen Anwendungen wie einem Remotewebdienst oder einem anderen System? Wenn abhängige Anwendungen mit der erforderlichen Auslastung nicht Schritt halten, wird die Gesamtleistung des Systems entsprechend beeinträchtigt.
Hardwareinformationen, die während der Bereichsphase berücksichtigt werden sollten
Erstellen Sie beim Eingrenzen der Lösung ein allgemeines Hardwarediagramm, das Folgendes enthält:
Computerarchitektur (z. B. x86, x64 und IA64)
CPU-Anforderungen (z. B. Typ, Geschwindigkeit, Anzahl, Kerne und Verwendung von Hyperthreading)
RAM-Anforderungen für jeden Computer
Lokaler Datenträgerspeicher (Typ, Größe, Geschwindigkeit)
SAN (Speicheranforderungen: Anzahl der LUNS; SAN Karte-Typ)
Netzwerkkarten (Anzahl auf jedem Computer, 100 Megabit pro Sekunde (MBit/s) im Vergleich zu 1 Gigabit pro Sekunde (1 GBit/s).)
Wie werden Firewalls in der Lösung bereitgestellt?
Wird Hardware für den Netzwerklastenausgleich verwendet?
Müssen bestimmte Computer gruppiert werden?
Softwareinformationen, die während der Gültigkeitsphase berücksichtigt werden sollten
Ebenso wichtig wie die Hardwareinformationen ist der Softwarestapel, der während der Leistungsbewertung verwendet wird. Stellen Sie sicher, dass Sie die folgenden Informationen dokumentieren:
Betriebssystem für jeden Computer ( 32 oder 64 Bit, gruppiert oder nicht).
Serversoftware, die auf jedem Computer installiert werden soll.
Verwendete Virtualisierungssoftware.
Bestimmte Softwarefeatures, die in der Regel nicht installiert sind, z. B. COM+-Rollupfixes oder SQL Server erforderlichen Hostfixes.
Ermitteln, ob Codeänderungen innerhalb des Bereichs der Leistungsbewertung liegen
Dies ist eines der wichtigsten Punkte, die während des Eingrenzungsprozesses zu bestimmen sind. BizTalk Server und die zugrunde liegenden Komponenten (SQL Server, Windows, IIS und viele mehr) können mithilfe der in diesem Handbuch beschriebenen Optimierungstechniken und Konfigurationsänderungen optimiert werden. Wenn eine Anwendung jedoch nicht für eine optimale Leistung entwickelt wurde, kann dies diese Leistungssteigerungen behindern. Daher sollten Codeänderungen nur dann aus dem Bereich entfernt werden, wenn Sie vertrauen, dass eine gründliche Codeüberprüfung abgeschlossen wurde, bevor die Anwendung das Lab betritt. Bei Bedarf können Sie sich damit einverstanden erklären, dass nur bestimmte Änderungen zulässig sind, z. B. das Entfernen von Persistenzpunkten innerhalb von Orchestrierungen.
Rollen und Zuständigkeiten
Einer der wichtigsten Bereiche bei der Durchführung einer Leistungsbewertung besteht darin, sicherzustellen, dass die Rollen und Zuständigkeiten klar zugewiesen sind. Die folgenden Schlüsselrollen sollten zu Beginn der Leistungsbewertung zugewiesen werden:
Engagement-Lead : Der Engagement-Lead ist für die End-to-End-Bindung des gesamten Engagements verantwortlich. Diese Rolle wird in der Regel von einem Senior Consultant oder Architekten ausgeführt. Im Idealfall sollte diese Person Erfahrung in der Optimierung BizTalk Server basierten Systemen haben. Kenntnisse über SQL Server und alle anderen Technologien, einschließlich von Drittanbietern, sind wünschenswert. Bitte beachten Sie, dass es nicht notwendig ist, dass der Lead ein Experte in allen Bereichen ist, aber er muss mindestens über ein funktionierendes Wissen über die Technologie verfügen, damit er mit den Spezialisten in diesen Bereichen zusammenarbeiten und die von ihnen angewendeten Optimierungen verstehen kann.
Testdesigner : Es ist erforderlich, jemanden zu haben, der sich mit dem Entwerfen und Implementieren der Tests beschäftigt, die während des Labs ausgeführt werden. Dies umfasst die Entscheidung über das Testframework, das zum Erstellen von Tests verwendet wird, das Testen der einzelnen Tests, um sicherzustellen, dass es die Anforderungen des Labs erfüllt, und sicherstellen, dass die für die Ausführung der Tests verantwortlichen Personen wissen, wie der Client verwendet wird.
Umgebungsbesitzer: Eine repräsentative Umgebung im Lab, die die Produktionsumgebung BizTalk Server genau widerspiegelt, ist von entscheidender Bedeutung. Die Person, die diese Rolle ausführt, ist dafür verantwortlich, jedes Element des verwendeten Software- und Hardwarestapels zu überprüfen und zu überprüfen, ob es keine wesentlichen Unterschiede gibt. Beispielsweise kann SQL Server 2008 R2 bei Ausführung auf der 32-Bit-Plattform nur 4 GB physischen Arbeitsspeicher adressieren, ohne physische Adresserweiterungen (PAE) oder Adressfenstererweiterungen (Address Windowing Extensions, AWE) zu verwenden. In SQL Server 2008 R2 kann 64 Bit bis zu 1 Terabyte Arbeitsspeicher adressiert werden (dies ist der aktuelle maximale physische Arbeitsspeicher, der von Windows Server 2008 R2 unterstützt wird). Ein wesentlicher Unterschied zwischen dem Kunden und der Labumgebung wäre daher die Architektur der CPU, die von BizTalk Server und SQL Server verwendet wird. Zusätzlich zu diesen offensichtlichen Faktoren können sich andere weniger offensichtliche Faktoren, z. B. installierte Service Pack-Level und Hotfixes, auf die Leistung der Umgebung auswirken.
Erstellen einer Umgebung : Nachdem eine detaillierte Spezifikation für die Leistungsbewertung erstellt wurde, sollte jemand die Verantwortung für die Erstellung der Umgebung zugewiesen werden. Dies umfasst den Hardware- und Softwarestapel. In vielen Fällen ist eine Person dafür verantwortlich (dies ist oft der Umgebungsbesitzer). In einem großen Unternehmen muss der Umgebungsbesitzer jedoch möglicherweise die Verbindung zwischen verschiedenen Teams sein, die jeweils für verschiedene Komponenten der Lösung verantwortlich sind. Beispielsweise kann ein Team für den Windows-Build, ein anderes für SQL Server und ein anderes Team für BizTalk Server verantwortlich sein.
Bereitstellungsleiter: Es ist erforderlich, dass jemand dafür verantwortlich ist, sicherzustellen, dass die Anwendung ordnungsgemäß für BizTalk Server bereitgestellt wird, dass die richtigen Bindungen konfiguriert sind und dass jede benutzerdefinierte Konfiguration angewendet wird. Diese Rolle erfordert umfassende Kenntnisse der Lösung und erfordert das Wissen, um eine Anwendung zu packen und bereitzustellen und dann zu überprüfen, ob sie sich in der Labumgebung in einem funktionierenden Zustand befindet.
Produktspezialisten – Es ist wichtig zu ermitteln, welche Produktspezialisten für die Leistungsbewertung benötigt werden. Welche Fähigkeiten genau benötigt werden, hängt vom Design und Zweck der BizTalk Server Anwendung ab.
Eine der am häufigsten benötigten Produktspezialistenkenntnisse sind umfassende Kenntnisse in der Leistungsoptimierung SQL Server. Diese Fähigkeiten sind für zwei Zwecke erforderlich: Erstens ist es häufig erforderlich, SQL Server Optimierungen durchzuführen, um die Leistung der BizTalk-Datenbanken zu optimieren, und zweitens verwenden viele BizTalk-Lösungen benutzerdefinierte Datenbanken. Die Verwendung benutzerdefinierter Datenbanken kann zu einem Engpass in der Lösung werden, wenn die richtigen Optimierungen nicht auf die SQL Server Umgebung angewendet werden. Um die entsprechenden Datenbankoptimierungen zu identifizieren und anzuwenden, sind in der Regel die folgenden SQL Server Fähigkeiten erforderlich:
Gründliches Verständnis SQL Server gespeicherten Prozedurcode, einschließlich der Möglichkeit, vorhandene gespeicherte Prozeduren zu optimieren.
Möglichkeit, fehlende Datenbankindizes zu identifizieren und zu erstellen.
Möglichkeit zum Schreiben von Skripts, um Datenbanken in mehrere Dateien aufzuteilen.
Hinweis
Weitere Informationen zum Anwenden dieser Optimierung finden Sie unter Optimieren von Dateigruppen für datenbanken2.
Möglichkeit, Leistungsprobleme mithilfe SQL Server 2008 R2 Leistungsdashboardberichte zu identifizieren.
Für jede an der Leistungsbewertung beteiligte Fachtechnologie sollte ein Anforderungsverzeichnis definiert werden, wie dies für SQL Server oben geschehen ist. Dadurch wird sichergestellt, dass die erhaltene Ressource klare Erwartungen an das hat, was von ihnen benötigt wird. Eine weitere Technologie, die bei der Leistungsbewertung häufig Spezielles Wissen erfordert, ist IBM Websphere MQ. Die folgende Liste veranschaulicht die Anforderungsspezifikation für einen IBM WebSphere MQ-Produktspezialisten:
Erfahrung in der Überwachung, Wartung und Anpassung von MQSeries.
Erfahrung mit der Installation und Migration neuer Versionen von MQSeries.
Möglichkeit zum Analysieren und Optimieren der MQSeries-Leistung.
Führen Sie eine MQSeries-Problemanalyse durch.
Kenntnisse der Prozesse und Verfahren im Zusammenhang mit MQSeries-Sicherheit, Verwaltung, Wiederherstellung und Automatisierung.
Dokumentationsleiter : Die fortlaufende Aktualisierung der Labdokumentation während der gesamten Leistungsbewertung ist von entscheidender Bedeutung. Der Gesamterfolg eines Lab-Engagements sollte erst beurteilt werden, wenn die Optimierungen in der Produktionsumgebung erfolgreich angewendet wurden und das System das gewünschte Leistungsniveau erreicht hat. Dazu ist es unerlässlich, dass die folgenden Informationen detailliert erfasst werden:
Allgemeine Ergebniszusammenfassung des Labs
Ungelöste Probleme
Behobene Probleme
Zeitachse für das Lab
Labstatus
Implementierte Optimierungen nach Kategorie
Implementierte Optimierungen in chronologischer Reihenfolge (um sicherzustellen, dass sie in derselben Reihenfolge im Produktionssystem angewendet werden können)
Allgemeines Architekturdiagramm
Detail der zu testenden Szenarien
Beteiligte Technologien von Drittanbietern
Labhardwarediagramm
Kontaktliste
Detaillierte Hardwareinventur
Anhang mit vollständigen detaillierten Ergebnissen
Entwickler : Ob ein Entwickler erforderlich ist, hängt stark vom Umfang des Engagements ab. Wenn die Codebasis gesperrt wurde und das Lab nur zum Testen von Infrastruktur- und Plattformoptimierungen da ist, sollten die Dienste eines Entwicklers nicht erforderlich sein. Diese Art von Szenario kann auftreten, wenn Leistungstests kurz vor dem "Go-Live"-Datum des Produktionsservers durchgeführt werden. Zu diesem Zeitpunkt sollte der Code gesperrt sein, und vollständige Regressionstests sollten abgeschlossen oder in Bearbeitung sein. Alle änderungen am Code, die im Lab eingeführt wurden, können zu einer Regression führen und somit ein Risiko für das Produktionssystem darstellen. Wenn Codeänderungen zulässig sind, ist in der Regel ein Entwickler erforderlich. Die folgende Liste stellt die Fähigkeiten dar, die normalerweise von einem Entwickler benötigt werden, der an einer BizTalk Server Leistungsbewertung beteiligt ist:
Fähigkeit, Leistungsprobleme mit Orchestrierungen zu identifizieren und zu beheben
Fähigkeit, Leistungsprobleme mit Pipelines zu identifizieren und zu beheben
Vertrautheit mit .NET, einschließlich:
Unternehmensbibliothek
Erfahrung mit Visual Studio F1-Profilern
Microsoft Visual Studio 2010 Ultimate oder Visual Studio Test Professional 2010
Testleiter : Es ist entscheidend, dass ein genauer, vollständiger und gründlicher Satz von Ergebnissen erzielt wird. Der Testleiter ist dafür verantwortlich, sicherzustellen, dass die erforderlichen Informationen nach jedem Testlauf erfasst, entsprechend analysiert und verteilt werden. Es ist wichtig zu überlegen, wie die Daten erfasst werden. In der Regel eignen sich die Testdaten für die Präsentation mithilfe einer Excel-Kalkulationstabelle. Die folgende Liste veranschaulicht die Daten, die für jeden Test erfasst werden sollen, der während des Labs ausgeführt wird:
Testlaufnummer
Date
Verarbeitete Nachrichten gesamt
Verarbeitete Nachrichten pro Sekunde
Startzeit
Angehaltene Zeit
Testdauer in Minuten
Angehaltene Nachrichten/Verarbeitete Nachrichten gesamt: Dies kann entweder über die BizTalk-Verwaltungskonsole oder durch Messen der BizTalk Server Leistungsindikatoren mithilfe von Leistungsmonitor erfasst werden.
Anzahl von Nachrichten, bei denen die Verarbeitung fehlgeschlagen ist
# oder Nachricht, die erfolgreich verarbeitet wurde
Testen von Clientantworten
Durchschnittliche Clientprozessdauer, gemessen in Sekunden: In der Regel wird dieser Wert bei der Implementierung einer synchronen Messaginglösung mit BizTalk Server gemessen. In diesem Fall ist es wichtig, den Wert für die durchschnittliche Clientdauer zu kennen, da dies in der Regel repräsentativ dafür ist, wie lange ein Endbenutzer auf eine Antwort von der Lösung wartet.
Maximalwert der Clientprozessdauer, gemessen in Sekunden
Mindestwert der Clientprozessdauer, gemessen in Sekunden
BizTalk Server Anforderungs-/Antwortlatenz, gemessen in Sekunden
Abgeschlossene Orchestrierungen pro Sekunde
% der rechtzeitig verarbeiteten Nachrichten
Wert der TestResultsLocation-Variable , die von Visual Studio Team System-Testtools verwendet wird.
Wert der testResultsLocation-Variablen , die von BizUnit verwendet wird.
Kommentare oder Empfehlungen
Neben der Erfassung der Ergebnisse sollte der Testleiter sicherstellen, dass er jeden Testlauf überwacht, um festzustellen, ob Trends vorliegen. Leistungsverbesserungen sollten dem Rest des Teams mitgeteilt werden und angeben, wie stark die Leistung verbessert wurde und welche Optimierung angewendet wurde, um die Verbesserung zu erreichen. Am Ende des Tages ist es wichtig, dass der Testleiter eine Zusammenfassung der Tests liefert, die im Labor durchgeführt wurden. Dies ermöglicht es den Projektbeteiligten, über den kontinuierlichen Fortschritt des Labs auf dem Laufenden zu bleiben. Die folgende Tabelle veranschaulicht, wie diese Informationen in einer Beispiel-Update-E-Mail zusammengefasst werden können:
Zusammenfassung der Testergebnisse
Status Throughput Durchschnittliche Latenz %< 2 Sekunden Anzahl der Testausführungen Anzahl der BizTalk Server Computer Anzahl von Nachrichten Durchschnittliche Nachrichtengröße Duration Aufskalieren 140 Nachrichten/Sekunde 0,777 Sekunden 99.3% 2 6 270.000 609 Bytes 30 Minuten Sehr hoch 50 Nachrichten/Sekunde 1,12 Sekunden 99.12% 17 2 360.000 609 Bytes 2 Stunden Grundwert 30 Nachrichten/Sekunde 1,52 Sekunden 92.9 % 4 2 36.000 609 Bytes 20 Minuten Ziele 5 Nachrichten/Sekunde < 2 Sekunden 90% - 2 - - -
Definieren aller Ergebnisse, die zu Beginn der Leistungsbewertung erforderlich sind
Es ist wichtig, sich auf Die Ergebnisse zu einigen, die vorhanden sein müssen, bevor eine BizTalk Server Leistungsbewertung eingeleitet wird. Im folgenden Abschnitt werden die Ergebnisse beschrieben, die zu Beginn der Leistungsbewertung vorhanden sein sollten.
Zu testende Anwendung : Die vollständige Anwendung, die während der Leistungsbewertung verwendet wird, muss verfügbar sein. Es ist wichtig, dass sich die Anwendung vor Beginn der Leistungsbewertung in einem voll funktionsfähigen Zustand befindet, da andernfalls das Risiko besteht, wertvolle Zeit für Labortests zu verlieren.
Planen des automatisierten Builds und der bereitstellung: Vor der Leistungsbewertung sollte ein automatisierter Build- und Bereitstellungsprozess für die BizTalk Server lösung entwickelt werden, die getestet werden soll. Durch die Automatisierung des Buildprozesses für eine Anwendung können Sie einen kontinuierlichen täglichen Buildprozess durchführen, der dann von einer Reihe von Buildvalidierungstests (BVTs) begleitet werden kann, die die Funktionsflüsse durch das System testen. Dadurch können Sie Kompilierungs- und Funktionsprobleme während des gesamten Entwicklungslebenszyklus schneller und einfacher erkennen. Innerhalb des Labs bedeutet dies, dass Sie, wenn Codeänderungen erforderlich sind, schnell überprüfen können, ob die aktualisierte Lösung problemlos funktioniert. Das manuelle Erstellen, Bereitstellen und Konfigurieren einer Anwendung für ein Leistungslabor kann eine mühsame und fehleranfällige Aufgabe sein. Daher wird empfohlen, eine Automatisierungstechnik zu verwenden, um die folgenden Build- und Bereitstellungsaktivitäten auszuführen:
Rufen Sie den neuesten Code aus der Quellcodeverwaltung ab.
Erstellen Sie die vollständige Lösung.
Stellen Sie die Lösung in der Umgebung bereit.
Erstellen sie BizTalk-Anwendungen.
Fügen Sie BizTalk Server Ressourcen wie .dll Dateien und Bindungen zu BizTalk-Anwendungen hinzu.
Importieren Sie die Bindungsdatei, um Ports zu erstellen und an Orchestrierungen zu binden.
Exportieren Sie BizTalk-Anwendungen als Microsoft® Windows® Installer-Paket, damit sie in der Test- oder Produktionsumgebung bereitgestellt werden können.
Hinweis
Weitere Informationen zum Implementieren eines automatisierten Buildprozesses finden Sie unterAutomatisieren des Buildprozesses.
MSBuild wurde mit .NET Framework 2.0 eingeführt, damit Entwickler Aufgaben wie die zuvor beschriebenen automatisieren können. Mehrere BizTalk Server-spezifische MSBuild-Aufgaben sind in der SDC-Aufgabenbibliothek enthalten, die unter https://go.microsoft.com/fwlink/?LinkId=119288heruntergeladen werden kann.
Testdaten, die bei der Leistungsbewertung verwendet werden sollen – Die verwendeten Testdaten haben einen erheblichen Einfluss auf die Gesamtwirksamkeit und den Erfolg einer Leistungsbewertung. Betrachten Sie das Szenario, in dem eine BizTalk Server-Anwendung Messaging, Orchestrierung und die Regel-Engine verwendet. Die Regel-Engine wird von einer Pipelinekomponente auf der Empfangsseite aufgerufen, um zu bestimmen, welche Orchestrierung zum Verarbeiten der Nachricht verwendet wird. und es wird auch von innerhalb der Orchestrierung an verschiedenen Stellen aufgerufen, um den Fluss zu bestimmen. Die Regel-Engine implementiert die Zwischenspeicherung, sodass die Ausführung der Regelrichtlinien optimiert wird. Wenn daher während der Leistungsbewertung eine einzelne Nachricht als Testdaten verwendet wird, können die Testergebnisse (aufgrund der Zwischenspeicherung) verzerrt sein, und Sie erhalten möglicherweise Ergebnisse, die nicht in der Produktion repliziert werden können.
Im Idealfall sollten die bei der Leistungsbewertung verwendeten Testdaten tatsächliche Produktionsdaten oder eine Teilmenge von Produktionsdaten sein. Die Testdaten sollten auch die Auslastung und das Muster des Datenverkehrs simulieren, der durch das Produktionssystem fließt. Berücksichtigen Sie beim Definieren von Anforderungen für Testdaten die folgenden Faktoren:
Anzahl der Nachrichten, die in einem bestimmten Zeitraum durch das System fließen: Dies wird normalerweise als Nachrichten pro Sekunde oder als Nachrichten pro Stunde ausgedrückt.
Nachrichtentypen : Sind die Nachrichten flatfile, XML oder binär?
Verteilung von Nachrichten : Welcher Prozentsatz ist Flatfile, welcher Prozentsatz der einzelnen XML-Nachrichtentypen wird verwendet?
Lastspitzenverarbeitungsanforderungen : In vielen Szenarien kann ein großer Austausch während der Spitzenzeiten verarbeitet werden. Beispielsweise kann eine große Zahl von Zahlungen um Mitternacht an die Systeme einer Bank gebucht werden. Wenn dies der Fall ist, stellen Sie sicher, dass Sie dies während des Tests replizieren können.
Endpunkte, die zum Empfangen/Senden von Nachrichten verwendet werden : In vielen Umgebungen sind separate Empfangsorte für den Empfang verschiedener Arten von Nachrichten konfiguriert. Beispielsweise können Flatfilenachrichten mithilfe des Dateiadapters oder mit dem MQSeries-Adapter empfangen werden, um XML-Nachrichten zu empfangen. Nachrichten können zwar alle von denselben Orchestrierung(en) verarbeitet werden, haben jedoch unterschiedliche Einstiegspunkte in das System. Jeder dieser verschiedenen Empfangsorte kann in einem separaten Host gehostet werden. dies verbessert häufig die Gesamtleistung des Systems.
Die folgende Tabelle enthält ein Beispiel für die Informationen, die beim Bestimmen von Testdatenspezifikationen erfasst werden sollten:
Beispieltestdatenspezifikation
| Category | BESCHREIBUNG |
|---|---|
| Nachrichten pro Sekunde | – Der maximale Durchsatz ist in diesem Szenario entscheidend - Ziel von 50 Nachrichten pro Sekunde - Niedrige Latenz ist kein Ziel |
| Nachrichtentyp | - Kleine XML-Nachrichten, ca. 25 KB, die dem XML-Schema X entsprechen - Mittlere XML-Nachrichten, ca. 512 KB, die dem XML-Schema Y entsprechen |
| Verteilung von Nachrichten | - 58% 25 KB (kleine XML-Nachrichten) - 25 % 512 KB (mittlere XML-Nachrichten) - 11% 3 MB (mittlere Binärdaten – PDF) – nicht komprimierbar - 4% 7,5 MB (große Binärdaten – PDF) – nicht komprimierbar) - 2% 20 MB (große Binärdaten – PDF) – nicht komprimierbar |
| Anforderungen an die Verarbeitung von Spitzenlasten | Große binärdaten (20 MB) stellen ungefähr 2 % der Daten dar (wie oben angegeben), der Zeitpunkt, zu dem diese verarbeitet werden, ist nicht vorhersagbar. Das System muss in der Lage sein, diese großen Nachrichten jederzeit unterzubringen. |
| Endpunkte, die zum Empfangen/Senden von Nachrichten verwendet werden | Kleine XML-Nachrichten (25 KB) - Empfangsstandort: PaymentXMLDocIn - Host: ReceiveHost - Verwendete Pipeline: XMLReceive Mittlere XML-Nachrichten (512 KB) - Empfangsstandort: PaymentXMLDocIn - Host: ReceiveHost - Verwendete Pipeline: XMLReceive Mittlere Binärdaten (3 MB) – PDF – nicht komprimierbar - Empfangsspeicherort: BinaryDataIn - Host: ReceiveHost - Verwendete Pipeline: PassThruReceive Große binärdaten (7,5 MB – 20 MB) – PDF – nicht komprimierbar - Empfangsspeicherort: BinaryDataIn - Host: ReceiveHost - Verwendete Pipeline: PassThruReceive |
| Speicherort der Testdaten | Lokal zugängliche Testdatendateifreigabe, z. B.: \\PerformanceLabs\July\Test Data\ |
Das Einfügen der Informationen in eine Tabelle führt zu mehreren Aufgaben. Erstens erleichtert es den Beteiligten, sich auf Annahmen zu einigen, die über die Testdaten getroffen wurden. Zweitens erhalten Sie Informationen, mit denen Sie über mögliche Optimierungen für die Leistungsbewertung entscheiden können. In der obigen Tabelle können Sie beispielsweise sehen, dass alle Empfangsspeicherorte, die zum Verarbeiten aller verschiedenen Datentypen verwendet werden, innerhalb des ReceiveHost BizTalk-Hosts gehostet werden. Dies bedeutet, dass jeder instance dieses Hosts für die Verarbeitung verschiedener Arten und Größen von Daten (z. B. XML- und binäre nicht komprimierbare PDF-Daten) verantwortlich ist. Da jeder Host instance ein einzelner instance des BizTalk Server-Prozesses (BTSNTSVC.EXE) ist, kann dies zu einem Verarbeitungsengpass werden. Daher besteht in diesem Szenario eine sofort offensichtliche Optimierung für die Umgebung darin, die Leistungsverbesserung zu testen, wenn jeder Empfangsstandort in einen eigenen individuellen Host unterteilt wird. Der Zugriff auf die Testdateninformationen in einem tabellarischen Zusammenfassungsformat erleichtert die Beurteilung einfacher Optimierungen wie dieser.
- Planen von automatisierten Auslastungstests und Auslastungsgenerierung : Nachdem das Testdatenprofil für die Leistungsbewertung erstellt wurde, ist es wichtig, zu überlegen, wie Auslastungstests in der Umgebung durchgeführt werden. Für BizTalk Server Auslastungstest 2010 haben wir den Visual Studio 2010-Auslastungstest verwendet. Weitere Informationen zum Vereinfachen von Auslastungstests mit Visual Studio 2010 finden Sie unter Verwenden von Visual Studio zum Vereinfachen automatisierter Tests.