Skalierbares Anpassungsdesign in Microsoft Dataverse

Hinweis

Dies ist der erste Artikel in einer Serie von Artikeln über skalierbare Anpassungsdesigns. Während dieser Inhalt in separate Artikel unterteilt wurde, stellt er eine wholistische Ansicht von Konzepten, Problemen und Strategien zur Gestaltung skalierbarer Anpassungen dar. Jeder Artikel baut auf Konzepten auf, die in vorherigen Artikeln erstellt wurden. Sie können diese Artikel als einzelnes PDF-Dokument herunterladen, wenn Sie sie offline lesen möchten. Wählen Sie den LINK "PDF herunterladen " im Inhaltsverzeichnis aus.

Dieser Inhalt bezieht sich nur auf Dataverse-Standardtabellen , die Azure SQL verwenden. Dataverse Elastic-Tabellen verwenden Azure Cosmos DB und unterstützen keine Transaktionen. Elastische Tabellen weisen unterschiedliche Merkmale auf. Weitere Informationen zu elastischen Tabellen

Dataverse schützt sich und seine Benutzer vor langfristigen Aktivitäten, die sowohl die Reaktionszeiten für den Benutzer als auch die Stabilität und Reaktionsfähigkeit des Systems für andere Benutzer beeinträchtigen können.

Eine Herausforderung bei einigen Personen, die Dataverse-Lösungen implementieren, sind Fehler, die von der Plattform oder der zugrunde liegenden Microsoft SQL Server-Datenbank ausgelöst werden, wenn diese Schutzmaßnahmen wirksam werden. Diese Fehler werden oft so interpretiert, als ob die Plattform nicht in der Lage wäre, Anforderungen an das System zu skalieren oder diese fälschlicherweise zu beenden oder zu drosseln.

Diese Inhalte basieren auf Erfahrungen mit der Untersuchung und Adressierung der tatsächlich zugrunde liegenden Ursachen der meisten dieser Arten von Herausforderungen. In diesen Artikeln wird beschrieben, wie sich die Plattform vor den Auswirkungen dieser Anforderungen schützt, die dem System auferlegt wurden, und erläutert, warum dieses Verhalten am häufigsten das Ergebnis von benutzerdefinierten Implementierungen ist, die die Auswirkungen auf die Blockierung und Transaktionsnutzung innerhalb der Plattform nicht verstehen.

In diesem Inhalt wird auch beschrieben, wie die Optimierung einer benutzerdefinierten Implementierung, um diese Arten von Verhaltensweisen zu vermeiden, nicht nur Plattformfehler zu vermeiden, sondern auch eine bessere Leistung und Endbenutzerfreundlichkeit zu ermöglichen. Es bietet gute Entwurfspraktiken und identifiziert häufige Fehler, die vermieden werden sollen.

Die Herausforderung

Die Untersuchung und Bewältigung der Herausforderungen in diesem Bereich beginnt in der Regel, wenn bestimmte Arten von Fehlern und Symptomen im System auftreten. Diese Fehler und Symptome werden häufig als Probleme in der Plattform wahrgenommen, und der notwendige Korrekturschritt besteht darin, die Plattformeinschränkungen zu lockern, die in der Regel eine langsam ausgeführte Anforderung auslösen, um zu einem gemeldeten Fehler zu werden.

Während die Fehler kurzfristig vermieden werden können, indem einige der Plattformeinschränkungen gelockert werden, sind diese Einschränkungen aus guten Gründen vorhanden und sollen verhindern, dass eine übermäßig lange Ausgeführte Aktion andere Benutzer oder Systemleistung beeinträchtigt. Während die Einschränkungen gelockert werden könnten, um die Fehler zu vermeiden, würden die Benutzer weiterhin unter langsamen Reaktionszeiten leiden, und diese Leistungsprobleme belasten auch die Benutzererfahrung des Systems.

Daher ist es vorzuziehen, die Ursachen zu untersuchen, warum diese Einschränkungen ausgelöst und Fehler verursacht werden, und optimieren Sie dann die Codeanpassungen, um sie zu vermeiden. Dieser Ansatz bietet ein konsistentes und reaktionsfähiges System für die Benutzer.

Häufige Symptome

Diese Arten von Problemen weisen in der Regel eine Kombination von häufig auftretenden Symptomen auf, wie in der folgenden Tabelle gezeigt.

Symptom	Description
Langsame Anfragen	Benutzern werden langsame Reaktionszeiten für das System in bestimmten Bereichen angezeigt, z. B. bestimmte Formulare und Abfragen
Generische SQL-Fehler	Bestimmte Aktionen reagieren mit einem Plattformfehler, der einen generischen SQL-Fehler meldet. Dieser Fehler übersetzt häufig auf einer Plattformebene in ein SQL-Timeout.
Deadlocks	Plattformfehler melden, dass ein Deadlock aufgetreten ist, wodurch die Aktion beendet und zurückgesetzt werden muss.
Begrenzter Durchsatz	Insbesondere in Batchladeszenarien zeigt sich dies oft in einem langsamen Durchsatz, der langsamer erzielt wird, als es möglich sein sollte.
Zeitweilige Fehler / langsame Leistung	Ein wichtiger Indikator für diese Verhaltensweisen ist, dass die gleiche Aktion schnell oder unglaublich langsam sein kann und das Wiederholen viel schneller funktioniert oder einen Fehler verhindert.

In Wirklichkeit kann und wird eine Kombination dieser Symptome oft zusammen gemeldet, wenn diese Herausforderungen auftreten. Es ist nicht immer der Fall, dass diese Symptome ein Indikator für Probleme mit dem Design sind. Andere Probleme, z. B. Datenträger-E/A-Einschränkungen in der Datenbank oder ein Produktfehler, können ähnliche Symptome verursachen. Aber die häufigste Ursache dieser Art von Symptomen und daher ein werter Prüfwert, bezieht sich direkt auf das Design der benutzerdefinierten Implementierung und wie es sich auf das System auswirkt.

Warum sollten wir uns sorgen? Kümmert sich Dataverse nicht eigentlich darum...?

Es geht so weit wie möglich... Es verwendet jedoch Sperren und Transaktionen, um das System bei Bedarf vor Konflikten zu schützen.

Darüber hinaus bieten wir Ihnen Optionen, um Entscheidungen über Ihr bestimmtes Szenario zu treffen und zu entscheiden, wo es wichtig ist, den Zugriff auf Daten zu steuern. Diese Entscheidungen können jedoch falsch getroffen werden, und es ist möglich, unbeabsichtigte Folgen in benutzerdefiniertem Code einzuführen. Diese Probleme haben in der Regel Auswirkungen auf die Benutzererfahrung durch langsamere Reaktionszeiten, sodass das Verständnis der Auswirkungen bestimmter Aktionen zu konsistenteren und besseren Ergebnissen für Benutzer führen kann.

Grundlegendes zu Ursachen

Häufige Symptome haben Ursachen, die erzwingen, dass bestimmte Anforderungen langsam laufen und dann Plattformeinschränkungen auslösen. Das folgende Diagramm zeigt typische Symptome mit einigen der häufigsten Ursachen dieser Symptome.

Die zugrunde liegenden Auswirkungen von lang ausgeführten Transaktionen, Datenbankblockierung und komplexen Abfragen können sich gegenseitig überlappen und ihre Auswirkungen verstärken, um diese Symptome zu verursachen. Beispielsweise kann eine Reihe von abfragen, die unabhängig voneinander sind, zu langsamen Benutzerantwortzeiten führen, aber nur wenn sie Zugriff auf dieselben Ressourcen benötigen, werden die Antwortzeiten so langsam, dass sie zu Fehlern werden.

Design für Plattformeinschränkungen

Die Dataverse-Plattform hat viele bewusste Einschränkungen, die sie aufzwingt, um zu verhindern, dass eine Aktion zu nachteilig auf den Rest des Systems und daher auf die Benutzer wirkt. Dieses Verhalten kann frustrierend sein, da es spezifische Anfragen daran hindern kann, abgeschlossen zu werden und häufig Fragen darüber aufwirft, ob die Einschränkungen aufgehoben werden können. Dies ist selten ein guter Ansatz, wenn man die umfassenderen Auswirkungen betrachtet.

Wenn die Plattform wie beabsichtigt verwendet wird und eine Implementierung optimiert ist, ist es selten, dass es ein Szenario gibt, in dem diese Einschränkungen auftreten würden. Wenn Sie auf Einschränkungen stoßen, ist das fast immer ein Hinweis auf Verhaltensweisen, die Ressourcen im System übermäßig binden. Dies bedeutet, dass andere Anforderungen von demselben Benutzer oder anderen Benutzern nicht verarbeitet werden können. Obwohl es möglich sein kann, die Einschränkung für die blockierte Anforderung zu lockern, bedeutet dies tatsächlich, dass die ressourcen, die sie verbrauchen, noch länger gebunden sind, was größere Auswirkungen auf andere Benutzer verursacht.

Im Mittelpunkt dieser Einschränkungen steht die Idee, dass die Dataverse-Plattform entwickelt wurde, um eine transaktionsbasierte Multi-User-Anwendung zu unterstützen, bei der schnelle Reaktion auf die Benutzernachfrage die Priorität ist. Es ist nicht als Plattform für langanhaltende oder Batch-Verarbeitung vorgesehen. Es ist möglich, eine Reihe kurzer Anforderungen an Dataverse zu steuern, aber Dataverse ist nicht für die Verarbeitung von Batchverarbeitung konzipiert. Ebenso ist Dataverse bei Aktivitäten mit großer iterativer Verarbeitung nicht für diese iterative Verarbeitung ausgelegt.

In diesen Szenarien kann ein separater Dienst verwendet werden, um den lang andauernden Prozess zu hosten und kürzere Transaktionsanforderungen direkt an Dataverse weiterzuleiten. Beispielsweise ist es viel besser, Flow zu verwenden oder Microsoft SQL Server Integration Services (SSIS) anderweitig zu hosten und dann einzelne Erstellungs- oder Aktualisierungsanforderungen an Dataverse zu leiten, als mit einem Plug-in Tausende von Datensätzen, die in Dataverse erstellt werden, durchzugehen.

Es lohnt sich, die vorhandenen Plattformeinschränkungen zu kennen und zu verstehen, damit Sie sie im Anwendungsdesign zulassen können. Wenn diese Fehler auftreten, können Sie auch verstehen, warum sie auftreten und was Sie ändern können, um sie zu vermeiden.

Constraint	Description
Plug-In-Zeitüberschreitungen	• Plug-In-Timeout nach 2 Minuten. • Führen Sie lange ausgeführte Vorgänge in Plug-Ins nicht aus. Schützt die Plattform und den Sandkastendienst und letztendlich den Benutzer vor schlechter Benutzererfahrung.
SQL-Timeouts	• Anfragen an den SQL Server führen in der Regel nach 120 Sekunden zu einem Timeout, obwohl die Befehlszeitschranke in einigen Fällen länger ist. • Schützt vor lang laufenden Anfragen • Bietet Schutz innerhalb einer bestimmten Organisation und seiner privaten Datenbank • Bietet auch Schutz auf Datenbankserverebene vor übermäßiger Verwendung gemeinsam genutzter Ressourcen wie Prozessoren/Arbeitsspeicher
Workflowbeschränkungen	• Arbeitet unter einer Richtlinie für die faire Nutzung • Keine spezifischen harten Grenzwerte, sondern Ressourcen übergreifend innerhalb von Organisationen ausbalancieren. • Wenn die Nachfrage niedrig ist, kann eine Organisation volle Vorteile der verfügbaren Kapazität nutzen. Wo die Nachfrage hoch ist, werden Ressourcen und Durchsatz gemeinsam genutzt.
Maximale Anzahl gleichzeitiger Verbindungen	• Es gibt eine Plattformstandardeinstellung für einen maximalen Verbindungspoolgrenzwert von 100 Verbindungen vom Webserververbindungspool in IIS zur Datenbank. Dataverse ändert diesen Wert nicht. • Wenn Sie dies erreichen, ist es ein Hinweis auf einen Fehler im System; Sehen Sie sich an, warum so viele Verbindungen blockiert werden. • Bei mehreren Webservern mit jeweils 100 gleichzeitigen Datenbankverbindungen von typischen < 10 ms ergibt dies einen Durchsatz von > 10.000 Datenbankanforderungen pro Webserver. Dies sollte nicht erforderlich sein und könnte viel früher auf andere Herausforderungen stoßen.
ExecuteMultiple	• Die ExecuteMultiple Nachricht wurde entwickelt, um Sammlungen von Vorgängen zu unterstützen, die von einer externen Quelle an Dataverse gesendet werden. • Die Bearbeitung großer Gruppen dieser Anfragen kann wichtige Ressourcen in Dataverse binden, auf Kosten kritischerer Anfragen in Bezug auf die Antwortzeit von Benutzern.
Dienstschutzbeschränkungen	• Um eine konsistente Verfügbarkeit und Leistung für alle zu gewährleisten, wenden wir einige Grenzwerte für die Verwendung von APIs an. Diese Grenzwerte sind darauf ausgelegt, zu erkennen, wann Clientanwendungen außergewöhnliche Anforderungen an Serverressourcen stellen. • Weitere Informationen: Dienstschutz-API-Grenzwerte

Nächste Schritte

Um zu verstehen, wie die Plattformeinschränkungen angewendet werden, müssen Sie Datenbanktransaktionen verstehen. Weitere Informationen: Skalierbares Anpassungsdesign: Datenbanktransaktionen