Engpässe auf der BizTalk Server-Ebene
Die BizTalk-Ebene gliedert sich in die folgenden Funktionsbereiche:
Empfangen
Verarbeitung
Übertragung
Nachverfolgung
Sonstiges
Wenn die Systemressourcen (CPU, Arbeitsspeicher und Datenträger) für diese Bereiche ausgelastet zu sein scheinen, aktualisieren Sie den Server, indem Sie die Plattform basierend auf den Merkmalen Ihrer Anwendung hoch- oder hochskalieren. Wenn die Systemressourcen nicht überlastet sind, führen Sie die in diesem Abschnitt beschriebenen Schritte aus.
Engpässe im Empfangsspeicherort
Wenn sich Nachrichten am Empfangsspeicherort anhüpfen (z. B. der Dateieingangsordner wird groß), bedeutet dies, dass das System daten nicht schnell genug aufnehmen kann, um mit der eingehenden Last Schritt zu halten. Dies ist auf interne Drosselung zurückzuführen. Das heißt, BizTalk Server reduziert die Empfangsrate, wenn die Abonnenten Daten nicht schnell genug verarbeiten können, was zum Backlogaufbau in den Datenbanktabellen führt. Wenn der Engpass durch Hardwarebeschränkungen verursacht wird, versuchen Sie, hochzuskalieren. Weitere Informationen zum Hochskalieren finden Sie in den folgenden Themen in der Dokumentation zu BizTalk Server 2010:
Hochskalieren der BizTalk Server Ebene (https://go.microsoft.com/fwlink/?LinkId=158073).
Hochskalieren der SQL Server Ebene (https://go.microsoft.com/fwlink/?LinkId=158077).
Es ist auch möglich, eine horizontale Skalierung durchzuführen, indem einem Host instance (Server) zum Host hinzugefügt wird, der dem Empfangshandler zugeordnet ist. Weitere Informationen zum Herunterskalieren finden Sie in den folgenden Themen in der Dokumentation zu BizTalk Server 2010:
Horizontales Hochskalieren der BizTalk Server Ebene (https://go.microsoft.com/fwlink/?LinkId=158076).
Horizontales Hochskalieren der SQL Server Ebene (https://go.microsoft.com/fwlink/?LinkId=158075).
Verwenden Sie Perfmon, um die Ressourcennutzung auf dem System zu überwachen. Es muss in jedem Fall festgestellt werden, ob der Engpass durch den externen Empfangsspeicherort verursacht wird. Überprüfen Sie beispielsweise, ob die Remotedateifreigabe aufgrund hoher Datenträger-E/A-Vorgänge überlastet ist, der Server, der die ausgehende Remotewarteschlange hostet, nicht überlastet ist oder ob der Client, der zum Generieren von HTTP-Last verwendet wird, nicht auf Threads verhungert ist.
Verarbeitungsengpässe
Wenn der Leistungsindikator Hostwarteschlange – Länge steigt, gibt dies an, dass die Orchestrierungen nicht schnell genug abgeschlossen werden. Weitere Informationen finden Sie in der Perfmon-Zählertabelle in diesem Thema. Mögliche Gründe hierfür sind Speicherkonflikte oder CPU-Überlastung.
Wenn die Orchestrierungsserver den Engpass verursachen, ermitteln Sie die Quelle mit dem Systemmonitor.
Wenn der Server CPU-abhängig ist, ziehen Sie die folgenden Schritte in Betracht:
Wenn der Workflow komplex ist, sollten Sie erwägen, die Orchestrierung in mehrere kleinere Orchestrierungen aufzuteilen.
Hinweis
Das Aufteilen einer Orchestrierung in mehrere Workflows kann zusätzliche Wartezeit nach sich ziehen und die Komplexität erhöhen. Mehrere Workflows können auch zu einer Zunahme der Anzahl von Nachrichten führen, die in bizTalkMsgBoxDb veröffentlicht und von dieser genutzt werden, wodurch die Datenbank zusätzlich belastet wird.
Wenn Sie komplexe Zuordnungen verwenden, überlegen Sie, ob sie an die Empfangs-/Sendeports verschoben werden können. Vergewissern Sie sich, dass Sie überprüfen, welche Ports über zusätzliche Bandbreite verfügen.
Erwägen Sie das Hochskalieren der Hardware oder das Horizontalskalieren, indem Sie einen zusätzlichen Verarbeitungsserver konfigurieren.
Übermittlungsengpässe
Wenn der Server, der die Sendeadapter hostet, mit Ressourcen (z. B. Datenträger, Arbeitsspeicher oder CPU) überlastet ist, sollten Sie den Server hochskalieren oder auf zusätzliche Sendehostserver hochskalieren. Die Sendeebene kann zum Engpass werden, wenn das (für BizTalk externe) Ziel die Daten nicht schnell genug empfangen kann. Dadurch sammeln sich Nachrichten in der MessageBox-Datenbank (Anwendung SendHostQ) an.
Wenn sich alle Endpunkte im Bereich der Topologie befinden, isolieren Sie die Ursache am Ziel. Ermitteln Sie beispielsweise, ob der HTTP-Speicherort optimal für den Empfang von Ladevorgängen konfiguriert ist. Andernfalls sollten Sie eine Horizontale Skalierung in Erwägung ziehen. Ermitteln Sie auch, ob das Ziel aufgrund übermäßiger Ausgabenachrichten, die von BizTalk übermittelt werden, wächst. Wenn ja, benötigen Sie möglicherweise einen Wartungsplan, um die Zielnachrichten zu archivieren und zu löschen. Eine große Anzahl von Dateien in einem Zielordner kann die Fähigkeit des BizTalk-Diensts, Daten auf das Datenträgerlaufwerk zu commiten, erheblich beeinträchtigen.
Nachverfolgen von Engpässen
Der Nachverfolgungshost instance ist für das Verschieben der Daten zur Überwachung von Geschäftsaktivitäten (Business Activity Monitoring, BAM) und Integritäts- und Aktivitätsnachverfolgung (HAT) aus der MessageBox-Datenbank (TrackingData-Tabelle) in die Datenbanktabellen der BizTalk-Nachverfolgung und/oder des primären BAM-Imports verantwortlich. Wenn mehrere MessageBox-Datenbanken konfiguriert sind, verwendet der Nachverfolgungshost instance vier Threads pro MessageBox-Datenbank.
Es ist möglich, dass der Nachverfolgungshost instance CPU-gebunden ist. Wenn dies der Grund ist, sollten Sie den Server hochskalieren oder horizontal hochskalieren, indem Sie einen zusätzlichen Server mit aktivierter Hostnachverfolgung konfigurieren. Die mehreren Hostinstanzen werden automatisch einen Lastenausgleich für die mehrere konfigurierten MessageBox-Datenbanken ausführen. Weitere Informationen zur Skalierung finden Sie im Thema Skalieren Ihrer Lösungen (https://go.microsoft.com/fwlink/?LinkId=158078).
Wenn die Tabelle TrackingData in der MessageBox-Datenbank groß wird, liegt dies in der Regel daran, dass die Datenwartungsaufträge in der BizTalk-Nachverfolgungs- und/oder BAM-Primärimportdatenbank nicht wie konfiguriert ausgeführt werden, was zu einem Wachstum der BizTalk-Nachverfolgungs- und/oder BAM-Primärimportdatenbanken führt. Wenn diese Datenbanken zu groß werden, kann dies negative Auswirkungen auf die Fähigkeit des Trackinghosts haben, Daten in die Tabelle TrackingData einzufügen. Dies führt dazu, dass nachverfolgte Daten in den MessageBox-Datenbanktabellen gesichert werden. Das Wachstum der TrackingData-Tabelle führt dazu, dass die Drosselung gestartet wird.
Sie sollten nur die minimale Nachverfolgung aktivieren, die für Ihre Anwendung erforderlich ist, da dies die Menge der protokollierten Daten verringert und das Risiko von Nachverfolgungsengpässen verringert. Informationen zum Deaktivieren von Nachverfolgungseinstellungen für einzelne Elemente wie Orchestrierungen und Sende-/Empfangsports finden Sie unter Deaktivieren der Nachverfolgung (https://go.microsoft.com/fwlink/?LinkId=160064).
Sonstiges
Konfigurieren Sie die Bereitstellungstopologie so, dass in dedizierten isolierten Hostinstanzen unterschiedliche Funktionen ausgeführt werden. Auf diese Weise erhält jeder Host instance einen eigenen Ressourcensatz (z. B. auf einem 32-Bit-System, 2 GB virtueller Arbeitsspeicheradressraum, Handles, Threads). Wenn der Server über genügend CPU-Hauptraum und Arbeitsspeicher verfügt, um mehrere Hostinstanzen zu hosten, können sie für die Ausführung auf demselben physischen Computer konfiguriert werden. Andernfalls sollten Sie eine Horizontale Skalierung erwägen, indem Sie die Funktionalität auf dedizierte Server verschieben. Das Ausführen der gleichen Funktionen auf mehreren Servern führt zudem zu einer hoch verfügbaren Konfiguration.
BizTalk-Systemleistungsindikatoren
| Object | Instanz | Leistungsindikator | Überwachungszweck |
|---|---|---|---|
| Prozessor | _Total | % Prozessorzeit | Ressourcenkonflikte |
| Prozess | BTSNTSvc | Virtuelle Bytes | Speicherverlust/-überlastung |
| Prozess | BTSNTSvc | Private Bytes | Speicherverlust/-überlastung |
| Prozess | BTSNTSvc | Anzahl von Handles | Ressourcenkonflikte |
| Prozess | BTSNTSvc | Threadanzahl | Ressourcenkonflikte |
| Physikalischer Datenträger | _Instanz | % Leerlaufzeit | Ressourcenkonflikte |
| Physikalischer Datenträger | _Instanz | Durchschnittliche Warteschlangenlänge des Datenträgers | Ressourcenkonflikte |
CPU-Konflikte
Wenn der Prozessor gesättigt ist, können Sie die Anwendung fragmentieren, indem Sie den Empfangenden von der sendenden und der Orchestrierung trennen. Erstellen Sie zu diesem Zweck separate Hosts, ordnen Sie die Hosts bestimmten Funktionen (Empfang/Senden/Orchestrierungen/Nachverfolgung) zu, und fügen Sie diesen separaten Hosts dedizierte Server hinzu. Orchestrierungsfunktionen sind häufig CPU-intensiv. Wenn Sie das System so konfigurieren, dass die Orchestrierungen auf einem separaten dedizierten Server ausgeführt werden, kann dies zur Verbesserung des Gesamtsystemdurchsatzes beitragen.
Wenn mehrere Orchestrierungen bereitgestellt werden, können Sie sie auf verschiedenen dedizierten Orchestrierungshosts eintragen. Durch das Zuordnen verschiedener physischer Server zu den dedizierten Orchestrierungshosts wird sichergestellt, dass die verschiedenen Orchestrierungen isoliert sind und weder im gleichen physischen Adressraum noch auf demselben Server um freigegebene Ressourcen konkurrieren.
Beenden Sie nicht verwendete Hostinstanzen. Nicht verwendete Hostinstanzen können um CPU- und Arbeitsspeicherressourcen konkurrieren, indem sie die MessageBox regelmäßig auf zu verarbeitende Nachrichten überprüfen. Beenden Sie außerdem nicht verwendete Empfangsspeicherorte, Sendeports und Orchestrierungen.
Spooltabellenwachstum
Nachgeschaltete Engpässe und/oder Ressourcenkonflikte können dazu führen, dass der Spool übermäßig anwächst und die Gesamtleistung verringert wird. Weitere Informationen finden Sie unter "Spool Table Growth" in How to Identify Bottlenecks in the MessageBox Database1.
Arbeitsspeichermangel
Szenarien mit hohem Durchsatz können zu einer stärkeren Beanspruchung des Arbeitsspeichers führen. Da ein 32-Bit-Prozess durch die Menge an Arbeitsspeicher begrenzt ist, die er verbrauchen kann, wird empfohlen, die Empfangs-/Prozess-/Sendefunktionalität in separate Hostinstanzen zu unterteilen, sodass jeder Host einen eigenen Adressraum von 2 GB erhält. Wenn mehrere Hostinstanzen auf demselben physischen Server ausgeführt werden, können Sie außerdem ein Upgrade auf 4/8 GB Arbeitsspeicher durchführen, um zu vermeiden, dass Daten aus dem tatsächlichen Arbeitsspeicher auf den Datenträger ausgetauscht werden. Orchestrierungen mit langer Ausführungsdauer können den zugeordneten Arbeitsspeicher länger halten. Dies kann dazu führen, dass speicheraufblähen und Drosselung gestartet wird. Große Nachrichten können auch einen hohen Arbeitsspeicherverbrauch verursachen.
Sie können das Problem der Arbeitsspeicherauslastung, das auftritt, wenn große Nachrichten verarbeitet werden, verringern, indem Sie die Interne Nachrichtenwarteschlangengröße und die In-Process-Nachrichten pro CPU-Werte für den jeweiligen Host verringern.
Hinweis
Wenn die Latenz ein Problem darstellt, sollten Änderungen an der Größe der internen Nachrichtenwarteschlange und an den Prozessnachrichten pro CPU mit Vorsicht vorgenommen werden, da dies die End-to-End-Latenz des Systems erhöhen kann.
Datenträgerkonflikt
Wenn die Datenträger gesättigt sind (z. B. mit einer großen Anzahl von FILE/MSMQ-Transporten), sollten Sie ein Upgrade auf mehrere Spindeln in Betracht ziehen und die Datenträger mit RAID 10 strippen. Darüber hinaus ist es bei verwendung des FILE-Transports wichtig, sicherzustellen, dass die Empfangs- und Sendeordner nicht größer als 50.000 Dateien werden.
Der Empfangsordner kann groß werden, wenn BizTalk Server eingehende Daten in das System drosselt. Es ist wichtig, Daten aus dem Sendeordner zu verschieben, damit sich das Wachstum in diesem Ordner nicht auf die Fähigkeit von BizTalk Server auswirkt, zusätzliche Daten zu schreiben. Für nicht transaktionale MSMQ-Warteschlangen wird empfohlen, die Empfangswarteschlangen remote zu erstellen, damit die Datenträgerkonflikte auf der BizTalk Server reduziert werden.
Die Konfiguration der nicht transaktionalen Remotewarteschlange bietet auch Hochverfügbarkeit, da der Remoteserver, auf dem die Warteschlange gehostet wird, gruppiert werden kann.
Andere Systemressourcenkonflikte
Je nach Transporttyp kann es erforderlich sein, Systemressourcen wie IIS für HTTP zu konfigurieren (z. B. MaxIOThreads, MaxWorkerThreads).
Mit ASP.NET 2.0 und ASP.Net 4 konfiguriert die <einstellung processModel autoConfig="true"> in der machine.config-Datei automatisch die folgenden Einstellungen für eine optimale Leistung:
Maximale Anzahl von Workerthreads
Maximale E/A-Threads
minFreeThreads-Attribut des httpRuntime-Elements
minLocalRequestFreeThreads-Attribut des httpRuntime-Elements
maxConnection-Attribut des <connectionManagement-Elements> (Netzwerkeinstellungen)
Weitere Informationen zum Konfigurieren von Parametern, die sich auf die Adapterleistung auswirken, finden Sie unter ASP.NET Konfigurationseinstellungen für das processModel-Element (https://go.microsoft.com/fwlink/?LinkId=158080).
Weitere Informationen zu Konfigurationseinstellungen, die sich auf BizTalk Server Adapter auswirken können, finden Sie unter Konfigurationsparameter, die sich auf die Adapterleistung auswirken (https://go.microsoft.com/fwlink/?LinkID=154200).
Zusätzlich zur Optimierung Ihrer BizTalk Server Anwendungen können sich andere ASP.NET Anwendungen, die auf demselben Server ausgeführt werden, auf die Gesamtleistung auswirken. Es ist wichtig, alle Ihre ASP.NET Anwendungen zu optimieren, um den Bedarf an Systemressourcen zu reduzieren. Weitere Informationen finden Sie unter ASP.NET Performance (https://go.microsoft.com/fwlink/?LinkId=158081).
Bei der Konfiguration für maximale Leistung sollten Sie andere externe Systeme wie Messaging-Engines (Message Queuing, MQSeries), Anwendungen, Datenbanken, Active Directory usw. optimieren, die Teil Ihrer BizTalk-Gesamtlösung sind. Leistungsengpässe in einem dieser anderen externen Systeme können sich negativ auf Ihre BizTalk-Lösung auswirken.
Downstream-Engpässe
Wenn das Downstreamsystem daten nicht schnell genug von BizTalk empfangen kann, werden diese Ausgabedaten in den BizTalk-Datenbanken gesichert. Dies führt zu Aufblähungen, führt zum Starten einer Drosselung, verkleinert die Empfangspipe und wirkt sich auf den Gesamtdurchsatz des BizTalk-Systems aus. Ein direkter Hinweis darauf ist das Wachstum der Spool-Tabelle. Weitere Informationen zu Engpässen und der Spooltabelle finden Sie unter Identifizieren von Engpässen in der MessageBox-Datenbank1.
Auswirkungen der Drosselung
Die Drosselung wird schließlich beginnen, das System vor dem Erreichen eines nicht wiederherstellbaren Zustands zu schützen. Daher können Sie die Drosselung verwenden, um zu überprüfen, ob das System normal funktioniert, und die Ursache des Problems zu ermitteln. Nachdem Sie die Ursache des Engpasses durch den Drosselungszustand identifiziert haben, analysieren Sie die anderen Leistungsindikatoren, um die Ursache des Problems zu ermitteln. Beispielsweise kann ein hoher Konflikt in der MessageBox-Datenbank auf eine hohe CPU-Auslastung zurückzuführen sein, die durch übermäßige Auslagerung auf den Datenträger verursacht wird, die durch geringe Arbeitsspeicherbedingungen verursacht wird. Hohe Konflikte in der MessageBox-Datenbank können auch durch hohe Sperrenkonflikte aufgrund von gesättigten Datenträgern verursacht werden. Während die gelegentliche Drosselung keine erhebliche Bedrohung für die Leistung darstellt, kann die anhaltende Drosselung auf ein größeres zugrunde liegendes Problem hinweisen. Weitere Informationen zu den Bedingungen, unter denen BizTalk Server Drosselung verwenden, finden Sie unter How BizTalk Server Implements Host Drosselling (https://go.microsoft.com/fwlink/?LinkID=155286).
Weitere Informationen dazu, wie BizTalk Server Drosselung dabei helfen kann, die Verwendung verfügbarer Ressourcen zu verwalten und Ressourcenkonflikte zu minimieren, finden Sie unter Optimieren der Ressourcennutzung durch Hostdrosselung (https://go.microsoft.com/fwlink/?LinkID=155770).
BizTalk-Anwendungsindikatoren
| Object | Instanz | Leistungsindikator | Beschreibung |
|---|---|---|---|
| BizTalk Messaging | RxHost | Dokumente empfangen/s | Eingangsrate |
| BizTalk Messaging | TxHost | Dokumente verarbeitet/s | Ausgangsrate |
| XLANG/s-Orchestrierungen | PxHost | Abgeschlossene Orchestrierungen/s | Verarbeitungsrate |
| BizTalk : MessageBox: Allgemeine Leistungsindikatoren | MsgBoxName | Spoolgröße | Kumulative Größe aller Hostwarteschlangen |
| BizTalk : MessageBox: Allgemeine Leistungsindikatoren | MsgBoxName | Größe der Nachverfolgungsdaten | Größe der TrackingData-Tabelle der MessageBox-Datenbank |
| BizTalk:MessageBox:Host Counters | PxHost:MsgBoxName | Hostwarteschlange - Länge | Anzahl der Nachrichten in der jeweiligen Hostwarteschlange |
| BizTalk:MessageBox:Host Counters | TxHost:MsgBoxName | Hostwarteschlange - Länge | Anzahl der Nachrichten in der jeweiligen Hostwarteschlange |
| BizTalk:Nachrichtenagent | RxHost | Datenbankgröße | Größe der Veröffentlichungswarteschlange (PxHost) |
| BizTalk:Nachrichtenagent | PxHost | Datenbankgröße | Größe der Veröffentlichungswarteschlange (TxHost) |
| BizTalk:Nachrichtenagent | HostName | Status der Nachrichtenübermittlungseinschränkung | Betrifft XLANG- und ausgehende Transporte |
| BizTalk:Nachrichtenagent | HostName | Nachrichtenveröffentlichungsdrosselungsstatus | Betrifft XLANG- und eingehende Transporte |
Wo beginne ich?
Die Überwachung des Status der Nachrichtenübermittlungsdrosselung und des Status der Nachrichtenveröffentlichungsdrosselung für jeden Host instance ist ein guter Ausgangspunkt. Wenn der Wert dieser Indikatoren nicht 0 ist, bedeutet dies eine Einschränkung im BizTalk-System, und Sie können die Ursache des Engpasses weiter analysieren. Beschreibungen zu den anderen Leistungsindikatoren finden Sie unter Engpässe auf der Datenbankebene.
Leistungsindikatoren der Orchestrierungs-Engine
Es wird dringend empfohlen, die Einstellungen für die Orchestrierungslaufzeit zu optimieren, da kontinuierliche Orchestrierungsdehydrierung und Persistenzpunkte schwerwiegende Auswirkungen auf die Gesamtleistung haben können. Sie müssen die folgenden Leistungsindikatoren verwenden, wenn Sie komplexe Orchestrierungen testen, die möglicherweise mehrere Persistenzpunkte und Transaktionsbereiche enthalten.
| Leistungsindikator | Kommentare |
|---|---|
| Pausierte Orchestrierungen/s | Die durchschnittliche Anzahl der pro Sekunde pausierten Orchestrierungen. |
| Aktivierte Orchestrierungen/s | Die durchschnittliche Anzahl der pro Sekunde aktivierten Orchestrierungen. |
| Dauerhaftigkeitspunkte/s | Die durchschnittliche Anzahl der pro Sekunde dauerhaft gesicherten Orchestrierungsinstanzen. |
| Orchestrierungen im Speicher | Die Anzahl der Orchestrierungsinstanzen, die derzeit von der Hostinstanz gehostet werden. |
| Orchestrierung abgeschlossen/Sek. | Die durchschnittliche Anzahl der pro Sekunde abgeschlossenen Orchestrierungen. |
| Angehaltene Orchestrierungen/s | Die durchschnittliche Anzahl der pro Sekunde angehaltenen Orchestrierungen. |
| Transaktionsbereiche, für die ein Commit ausgeführt wurde/s | Die durchschnittliche Anzahl der Transaktionsbereiche, für die pro Sekunde ein Commit ausgeführt wurde. |
| Abgebrochene Transaktionsbereiche/s | Die durchschnittliche Anzahl der pro Sekunde abgebrochenen Transaktionsbereiche. |
| Kompensierte Transaktionsbereiche/s | Die durchschnittliche Anzahl der pro Sekunde kompensierten Transaktionsbereiche. |
Backlogaufbau
Bei einem 1-1-Bereitstellungsszenario, in dem eine empfangene Nachricht zu einer verarbeiteten und übertragenen Nachricht führt, liegt ein Backlog im System vor, wenn die Ausgehende Rate nicht der eingehenden Rate entspricht. In dieser Situation können Sie die Spoolgröße überwachen. Führen Sie bei der Ermittlung der Ursache von Engpässen bei der Ausgehenden Rate jeweils ein einzelnes Anwendungsfallszenario aus. Isolieren Sie Orchestrierungen, empfangen Sie Standorte und senden Sie Standorte an separate Hosts.
Fügen Sie bizTalk:Message Box:Host Counters zu Ihrem Leistungsmonitor Protokoll hinzu, um einen Host zu überwachen. Der Zähler Hostwarteschlange – Länge: verfolgt die Gesamtzahl der Nachrichten in einer bestimmten Hostwarteschlange. Wenn einer oder mehrere dieser Indikatoren im Laufe der Zeit weiter wachsen, achten Sie besonders auf die artefakte, die von diesen Hosts ausgeführt werden.
Wenn der Spool linear wächst, bestimmen Sie, welche Anwendungswarteschlange für das Spoolwachstum verantwortlich ist.
Wenn keine der Anwendungswarteschlangen wächst und der Spool weiter wächst, kann dies bedeuten, dass die Löschaufträge nicht schritthalten können. Dies tritt auf, wenn der Agent nicht ausgeführt wird oder andere Systemressourcenkonflikte auf dem SQL Server.
Wenn eine der Anwendungswarteschlangen wächst, diagnostizieren Sie die Ursache für dieses Wachstum. Überwachen Sie die Systemressourcen auf dem System, das die spezifische Anwendungswarteschlange nicht entladen kann (z. B. Orchestrierungshost-Q wächst aufgrund von CPU-Aushungern auf dem Server). Überprüfen Sie außerdem die Werte des Drosselungsindikators für den spezifischen Host instance.
Wenn die Leistungsindikatoren "BizTalk:Message Agent Message Delivery Drosselling State" und "Message Publishing Drosselling State" nicht 0 sind, überprüfen Sie den Wert, um den Grund für die Einschränkung zu bestätigen (z. B. Überschreitung des Speicherschwellenwerts, zu hohe Nachrichtenanzahl während des Flugs usw.).
Stand-Alone Profiler
Sie können Leistungsindikatoren verwenden, um den Speicherort des Engpasses auf hoher Ebene zu erkennen. Nach der Einschränkung müssen Sie den Code möglicherweise genauer untersuchen, um das Problem zu beheben. Die Stand-Alone Profiler, die im Lieferumfang von Visual Studio 2010 enthalten sind, kann ein sehr hilfreiches Tool sein, um zu diagnostizieren, wo der Code die meisten Zyklen aufwendet. Weitere Informationen finden Sie unter
L2/L3-Cache
Aus Hardwaresicht können Sie die größten Vorteile erzielen, indem Sie den integrierten CPU-Cache verwenden. Ein größerer CPU-Cache erhöht die Cachetrefferquote und verringert die Notwendigkeit, Daten aus dem Arbeitsspeicher auf die Festplatte auszulagern.
64-Bit-Leistungsengpässe
Es ist möglich, dass 64-Bit-Systeme scheinbar eine geringere Leistung erzielen als 32-Bit-Systeme. Dies ist aus mehreren Gründen möglich, wobei der wichtigste der Arbeitsspeicher ist.
Die Messung der Leistung auf einem 32-Bit-System mit 2 GB Arbeitsspeicher und der Vergleich der Ergebnisse mit einem ähnlichen 64-Bit-System mit 2 GB Arbeitsspeicher ist nicht dasselbe. Das 64-Bit-System scheint Datenträger-E/A-gebunden zu sein (niedrige % Leerlaufzeit des Datenträgers & hohe Datenträgerwarteschlangenlänge) und CPU-gebunden (maximale CPU- und hohe Kontextumschaltung). Dies liegt jedoch nicht daran, dass die Ausführung von Datei-E/A auf einem 64-Bit-System teurer ist.
Das 64-Bit-System ist arbeitsspeicherintensiver (64-Bit-Adressierung), was dazu führt, dass das Betriebssystem den größten Teil des verfügbaren 2 GB Arbeitsspeichers verbraucht. In diesem Fall verursachen die meisten anderen Vorgänge eine Paging auf den Datenträger, wodurch das Dateisubsystem belastet wird. Daher verbringt das System CPU-Zyklen, die sowohl Daten als auch Code ein- und auslagern, und wird von den hohen Kosten für die Datenträgerlatenz beeinträchtigt. Dies äußert sich sowohl in Form höherer Datenträgerkonflikte als auch in Form höherer CPU-Beanspruchung.
Um dieses Problem zu beheben, können Sie den Server hochskalieren, indem Sie den Arbeitsspeicher aktualisieren. Das Hochskalieren auf 8 GB ist eine Idee, aber das Hinzufügen von mehr Arbeitsspeicher trägt nicht dazu bei, den Durchsatz zu verbessern, es sei denn, die Ursache des Problems ist CPU-Mangel aufgrund geringer Arbeitsspeicherbedingungen.
Verwenden von BAM zum Identifizieren von Engpässen und Problemen mit hoher Latenz
Wenn eine geringe Latenz wichtig ist, können Sie BAM verwenden, um die Zeit zu messen, die das System benötigt, um jede Phase innerhalb des BizTalk Server Systems abzuschließen. Obwohl Sie HAT verwenden können, um den Status von Nachrichten zu debuggen und die Ursache von Problemen beim Weiterleiten von Nachrichten zu diagnostizieren, können Sie BAM verwenden, um verschiedene Punkte im Nachrichtenfluss nachzuverfolgen. Durch Erstellen eines BAM-Nachverfolgungsprofils, das eine Aktivität mit Fortsetzungen definiert, können Sie die Latenz zwischen verschiedenen Teilen des Systems messen, um die teuersten Phasen innerhalb des Workflowprozesses nachzuverfolgen.
Sie können den Orchestrierungsdebugger in HAT verwenden, um eine angehaltene instance abzufragen, die instance im Debugmodus fortzusetzen und entsprechende Haltepunkte mithilfe der Technischen Detailansicht hinzuzufügen. Auf diese Weise können Sie die Aktivitäten und Debugmeldungen schrittweise verfolgen.
Sie können Haltepunkte festlegen, um die folgenden Ereignisse zu überwachen:
Starten und Beenden einer Orchestrierung
Starten und Beenden einer Form
Senden oder Empfangen einer Nachricht
Ausnahmen
An jedem Haltepunkt können Sie Informationen zu lokalen Variablen, Nachrichten und deren Eigenschaften, Ports und Rollenverknüpfungen prüfen.