Skalierbares Anpassungsdesign in Microsoft Dataverse

Hinweis

Dies ist der erste in einer Reihe von Artikeln über skalierbares Anpassungsdesign. Obwohl dieser Inhalt in einzelne Artikel unterteilt wurde, bietet er einen ganzheitlichen Überblick über Konzepte, Probleme und Strategien rund um das Design skalierbarer Anpassungen. Jeder Artikel baut auf den Konzepten der vorangegangenen Artikel auf. Sie können diese Artikel als einzelnes PDF-Dokument herunterladen, wenn Sie sie offline lesen möchten. Wählen Sie im Inhaltsverzeichnis den Link PDF herunterladen.

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

Dataverse schützt sich und seine Benutzer vor zeitintensiven Aktivitäten, die sowohl die Antwortzeiten für den anfragenden Benutzer als auch die Stabilität und Reaktionsfähigkeit des Systems für andere Benutzer beeinflussen könnten.

Eine Herausforderung für einige Anwender bei der Implementierung von Dataverse-Lösungen sind Fehler, die von der Plattform oder der zugrunde liegenden Microsoft SQL Server-Datenbank verursacht werden, wenn diese Schutzmaßnahmen wirksam werden. Diese Fehler werden oft als die Plattform interpretiert, die nicht in der Lage ist, Anforderungen an das System zu skalieren oder falsch zu terminieren oder zu drosseln.

Dieser Inhalt basiert auf Erfahrungen, die die wahren Ursachen der meisten dieser Arten von Herausforderungen untersuchen und angehen. Diese Artikel beschreiben, wie sich die Plattform vor den Auswirkungen dieser Anforderungen an das System schützt, und erklären, warum dieses Verhalten meist das Ergebnis von benutzerdefinierten Implementierungen ist, die die Auswirkungen auf die Blockierung und Transaktionsnutzung innerhalb der Plattform nicht verstehen.

Dieser Inhalt beschreibt auch, wie die Optimierung einer benutzerdefinierten Implementierung zur Vermeidung solcher Verhaltensweisen nicht nur Plattformfehler vermeidet, sondern auch eine bessere Leistung und damit eine bessere Benutzerfreundlichkeit ermöglicht. Es bietet gute Designpraktiken und identifiziert häufige Fehler, die es zu vermeiden gilt.

Die Herausforderung

Die Untersuchung und Bewältigung der Herausforderungen in diesem Bereich beginnt in der Regel dann, wenn bestimmte Arten von Fehlern und Symptomen im System auftreten. Diese Fehler und Symptome werden oft als Probleme in der Plattform wahrgenommen, und der notwendige Abhilfeschritt besteht darin, die Plattformbeschränkungen zu lockern, die typischerweise dazu führen, dass eine langsam laufende Anforderung zu einem gemeldeten Fehler wird.

In Wirklichkeit könnten die Fehler zwar kurzfristig vermieden werden, indem einige der Plattformbeschränkungen gelockert werden, aber diese Beschränkungen gibt es aus guten Gründen und sollen verhindern, dass eine zu lange laufende Aktion andere Benutzer oder die Systemleistung beeinträchtigt. Während die Einschränkungen gelockert werden konnten, um die Fehler zu vermeiden, würden die Benutzer immer noch langsame Reaktionszeiten erleben, und diese Leistungsprobleme wirken sich auf die Erfahrung anderer Benutzer mit dem System aus.

Daher ist es vorzuziehen, die Ursachen dafür zu untersuchen, warum diese Einschränkungen ausgelöst werden und Fehler verursachen, und dann die Codeanpassungen zu optimieren, um sie zu vermeiden. Dieser Ansatz ermöglicht ein konsistenteres und reaktionsschnelleres System für die Benutzer.

Häufige Symptome

Diese Art von Problemen weist typischerweise eine Kombination von häufigen Symptomen auf, wie in der folgenden Tabelle dargestellt.

Symptom	Beschreibung
Langsame Abfragen	Benutzer sehen langsame Antwortzeiten für das System in bestimmten Bereichen, z. B. bestimmte Formulare und Abfragen.
Generische SQL-Fehler	Bestimmte Aktionen reagieren mit einem Plattformfehler, der einen Generic SQL Error meldet. Dieser Fehler übersetzt sich oft auf einer Plattformebene in einen SQL-Timeout.
Deadlocks	Plattformfehler, die melden, dass ein Deadlock aufgetreten ist, was dazu geführt hat, dass die Aktion beendet und zurückgesetzt wurde.
Begrenzter Durchsatz	Gerade in Batch-Load-Szenarien zeigt sich dies oft darin, dass ein langsamer Durchsatz erreicht wird, langsamer als es möglich sein sollte.
Intermittierende Fehler / langsame Leistung	Ein wichtiger Indikator für dieses Verhalten ist, dass die gleiche Aktion schnell oder unglaublich langsam sein kann, und ein erneuter Versuch funktioniert viel schneller oder vermeidet einen Fehler.

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, wie z. B. Einschränkungen der Festplatten-I/O in der Datenbank oder ein Produktfehler, können ähnliche Symptome verursachen. Aber die häufigste Ursache für diese Art von Symptomen, und damit eine, auf die es sich zu prüfen lohnt, bezieht sich direkt auf das Design der benutzerdefinierten Implementierung und wie sie sich auf das System auswirkt.

Warum sollten wir uns Sorgen machen? Kümmert sich Dataverse nicht einfach darum ...?

Es tut, was es kann... Aber es verwendet Sperren und Transaktionen, um das System bei Bedarf vor Konflikten zu schützen.

Wir bieten Ihnen auch Optionen, Entscheidungen über Ihr spezielles Szenario zu treffen und zu entscheiden, wo es wichtig ist, den Zugriff auf Daten zu kontrollieren. Aber diese Entscheidungen können falsch getroffen werden, und es ist möglich, unbeabsichtigte Konsequenzen in benutzerdefinierten Code einzubringen. Diese Probleme haben typischerweise Auswirkungen auf die Benutzerfreundlichkeit durch langsamere Reaktionszeiten, so dass das Verständnis der Auswirkungen bestimmter Aktionen zu konsistenteren und besseren Ergebnissen für die Benutzer führen kann.

Ursachen verstehen

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

Die zugrunde liegenden Auswirkungen von lang laufenden Transaktionen, Datenbankblockaden und komplexen Abfragen können sich alle überschneiden und ihre Auswirkungen verstärken, um diese Symptome zu verursachen. Beispielsweise kann eine Reihe von zeitintensiven Abfragen, die unabhängig voneinander sind, zu langsamen Benutzerantwortzeiten führen, aber erst wenn sie Zugriff auf die gleichen Ressourcen benötigen, werden die Antwortzeiten so langsam, dass sie zu Fehlern werden.

Design für Plattformbeschränkungen

Die Dataverse-Plattform hat viele bewusste Einschränkungen, die sie auferlegt, um zu verhindern, dass eine einzelne Aktion schädliche Auswirkungen auf den Rest des Systems und damit auf die Benutzer hat. Während dieses Verhalten frustrierend sein kann, da es das Abschließen spezifischer Anfragen blockieren kann und oft zu Fragen darüber führt, ob die Beschränkungen aufgehoben werden können, ist dies selten ein guter Ansatz, wenn man die breiteren Auswirkungen betrachtet.

Wenn die Plattform bestimmungsgemäß genutzt und eine Implementierung optimiert wird, ist es sehr 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 entweder vom gleichen Benutzer oder von anderen Benutzern nicht bearbeitet werden können. Während es also möglich ist, die Einschränkung der zu blockierenden Anforderung zu lockern, bedeutet das eigentlich, dass die Ressourcen, die sie verbraucht, noch länger gebunden sind und größere Auswirkungen auf andere Benutzer haben.

Im Mittelpunkt dieser Einschränkungen steht die Idee, dass die Dataverse-Plattform so konzipiert ist, dass sie eine transaktionale Mehrbenutzeranwendung unterstützt, bei der eine schnelle Reaktion auf die Benutzernachfrage im Vordergrund steht. Es ist nicht als Plattform für eine zeitintensive oder Stapelverarbeitung gedacht. Es ist möglich, eine Reihe von kurzen Anforderungen an Dataverse zu senden, aber Dataverse ist nicht für die Stapelverarbeitung ausgelegt. 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 laufenden Prozess zu hosten und kürzere transaktionale Anfragen an Dataverse selbst zu leiten. Beispielsweise ist es besser, Flows 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 Plattformbeschränkungen zu kennen und zu verstehen, damit Sie sie in Ihrem Anwendungsdesign berücksichtigen können. Wenn Sie auf diese Fehler stoßen, können Sie außerdem verstehen, warum sie passieren und was Sie ändern können, um sie zu vermeiden.

Einschränkung	Beschreibung
Plug-in-Zeitüberschreitungen	• Plug-In-Timeout nach 2 Minuten. • Führen Sie keine zeitintensiven Operationen in Plug-Ins durch. Schützt die Plattform und den Sandbox-Service und letztendlich den Benutzer vor einer schlechten Benutzererfahrung
SQL-Zeitüberschreitungen	• Bei Anforderungen an SQL Server beträgt das Timeout normalerweise 120 Sekunden, in manchen Fällen ist das Befehls-Timeout jedoch länger • Schützt vor lang laufenden Anfragen • Bietet Schutz innerhalb eines bestimmten Unternehmens und seiner privaten Datenbank • Bietet auch Schutz auf der Ebene des Datenbankservers vor übermäßiger Nutzung gemeinsamer Ressourcen wie Prozessoren/Speicher
Workflow-Begrenzungen	• arbeitet nach einer Richtlinie für eine faire Nutzung. • Keine spezifischen harten Grenzen, sondern Ressourcenausgleich zwischen Unternehmen • Bei geringer Nachfrage kann ein Unternehmen die verfügbare Kapazität voll ausschöpfen. Bei hoher Nachfrage werden Ressourcen und Durchsatz geteilt.
Maximale gleichzeitige Verbindungen	• Es gibt eine Plattformvoreinstellung für eine maximale Verbindungspoolgrenze von 100 Verbindungen aus dem Webserver-Verbindungspool im IIS zur Datenbank. Dataverse ändert diesen Wert nicht. • Wenn Sie darauf treffen, ist es ein Hinweis auf einen Fehler im System; schauen Sie sich an, warum so viele Verbindungen blockieren. • Bei mehreren Webservern mit jeweils 100 gleichzeitigen Verbindungen zur Datenbank mit typischen < 10 ms schlägt dies einen Durchsatz von > 10k Datenbankanforderungen für jeden Webserver vor. Dies sollte nicht erforderlich sein und würde andere Herausforderungen schon lange vorher treffen
ExecuteMultiple	• Die Nachricht ExecuteMultiple wurde entwickelt, um die Sammlungen von Vorgängen zu unterstützen, die an Dataverse von einer externen Quelle gesendet werden. • Die Verarbeitung großer Gruppen dieser Anforderungen kann wichtige Ressourcen in Dataverse auf Kosten von mehr antwortkritischen Anforderungen durch Benutzer binden.
Grenzwerte für den Serviceschutz	• Um eine konsistente Verfügbarkeit und Leistung für alle zu gewährleisten, wenden wir einige Einschränkungen für die Verwendung von APIs an. Diese Einschränkungen wurden entwickelt, um zu erkennen, wenn Client-Anwendungen außergewöhnliche Anforderungen an die Server-Ressourcen stellen. • Für weitere Informationen gehen Sie zu: API-Grenzwerte für den Serviceschutz

Nächste Schritte,

Um zu verstehen, wie die Plattformbeschränkungen angewendet werden, ist es notwendig, Datenbanktransaktionen zu verstehen. Mehr Informationen: Skalierbares Anpassungsdesign: Datenbanktransaktionen

Hinweis

Können Sie uns Ihre Präferenzen für die Dokumentationssprache mitteilen? Nehmen Sie an einer kurzen Umfrage teil. (Beachten Sie, dass diese Umfrage auf Englisch ist.)

Die Umfrage dauert etwa sieben Minuten. Es werden keine personenbezogenen Daten erhoben. (Datenschutzbestimmungen).