Ich stelle ein einfaches asp.net-Web-Steuerelement zusammen, das als Ergebnis eines Ajax-Formposts einen Datensatz in eine MSQL-Datenbank einfügt.
Es ist möglich, dass die Seite, die dieses Steuerelement enthält, innerhalb kurzer Zeit viele tausend Treffer erhält. Ich mache mir Sorgen über das Leistungsproblem beim Öffnen einer Datenbankverbindung, Einfügen des Datensatzes und Schließen der Verbindung für jede Anforderung.
Eine Lösung, die mir aufgefallen ist, ist, dass das Web-Steuerelement eine Nachricht in eine MSMQ-Warteschlange platziert und ein Windows-Dienst auf dem Server die Warteschlange periodisch liest und eine Batch-Einfügung durchführt.
Hört sich das nach einer vernünftigen Architektur an, wenn Web- und Datenbankserver auf demselben Computer ausgeführt werden. Klingt das notwendig?
Nach dem, was ich in der Datenbank gelesen habe, haben die meisten Vorteile der Verwendung von MSMQ eher mit der Resilienz als mit der Leistung zu tun, also könnte ich den falschen Baum bellen.
Jeder Rat würde sehr dankbar sein
Vielen Dank
Pete
Das Bearbeiten von Anforderungen auf diese Weise offline ist ein häufiges Muster, wenn Sie mit einer großen Anzahl von Anfragen arbeiten.
Ob Sie dies tun sollten oder können, hängt von einer Reihe von Faktoren ab.
Der Hauptfaktor ist: Müssen Ihre Anrufer die Antwort auf ihre Anfragen synchron sehen?
Was ich meine ist, muss der Anrufer sofort und mit absoluter Sicherheit wissen, ob die Datenbank ihre Daten erfolgreich als Teil der Anrufantwort übergeben hat? Wenn dies der Fall ist, ist es nicht wirklich eine Option, die Anfrage offline zu bearbeiten.
Wenn es jedoch akzeptabel ist, dass Anrufern eine Antwort gesendet werden kann, die besagt, dass ihre Anfrage offline verarbeitet wird (und jede erforderliche Antwort auch offline gesendet wird), wird die Verwendung einer Warteschlange definitiv der Gesamtarchitektur zugute kommen.
Das erste, was davon profitieren wird, sind Probleme bei der Verfügbarkeit von Front-End-Systemen.
Wenn Sie Tausende von Anfragen über einen kurzen Zeitraum bearbeiten und jede Anfrage von einem Thread bearbeitet wird, der dann verschwindet und Daten in eine Datenbank einfügt, werden Sie höchstwahrscheinlich auf das Problem stoßen, wo kein verfügbarer Dispatcher-Thread existiert eingehende Anfragen
Durch die Reduzierung der Back-End-Arbeit, die IIS ausführt (das Schreiben in eine lokale Warteschlange ist im Vergleich zu einem Datenbankaufruf jedoch relativ günstig), verringern Sie die Wahrscheinlichkeit eines Verfügbarkeitsfehlers.
Zweitens können Sie mithilfe einer Warteschlange den Back-End-Datenverkehr drosseln, da Sie den Durchsatz bei der Back-End-Verarbeitung kontrollieren können.
Sie könnten beispielsweise einen Warteschlangenleseprozess mit einem einzigen Thread haben, der eine Anfrage aus der Warteschlange nimmt und sie in eine Datenbank verarbeitet. Wenn Sie feststellen, dass sich Nachrichten in der Warteschlange befinden, können Sie den Warteschlangenleserdienst einfach durch Bereitstellen weiterer Instanzen erweitern.
Dies bedeutet, dass Sie die Wahrscheinlichkeit von Datenbankkonfliktproblemen reduzieren, da Sie die Anzahl der auf die Datenbank zugreifenden Threads zu einem bestimmten Zeitpunkt besser kontrollieren können.
Durch die Verwendung von Warteschlangen treten also weniger Fehler auf, und Sie haben einen geringeren Verwaltungsaufwand, der für gut geschriebene Anwendungen kennzeichnend ist. Dies insbesondere, wenn Sie in Betracht ziehen, Ihre Datenbank auf Ihrem Webserver zu hosten!
Sie sollten auch ein Architekturmuster mit dem Namen CQRS lesen, von dem eines der zentralen Prinzipien ist um Ihre Datenbank offline zu schreiben.
Eine asynchrone Architektur hat viele Vorteile (wie von Hugh identifiziert), hat aber definitiv größere Kosten und Komplexität. Dies sollte sorgfältig abgewogen werden. Aus 2 Komponenten (Web-App und DB) müssen Sie nun 4 Komponenten (Web-App, DB, Batch-Service, MSMQ) entwickeln, warten und überwachen. Sie haben gesagt, dass der Webserver und der DB-Server dieselbe Maschine ist, was bei Ihren Leistungsanforderungen seltsam ist. Morgen müssen Sie möglicherweise die Web-App, Batch-Service und DB 3 separate Maschinen hosten. Jetzt beinhaltet MSMQ auch das Netzwerk. Eine weitere Sache, die schief gehen kann. Multithread Batch-Prozessor ist auch nicht einfach, was, wenn Sie jede Nachricht in der Reihenfolge verarbeiten müssen, die sie generiert wurden (zumindest für eine bestimmte Entität) Logik kann komplex werden.
Wenn möglich, beide Lösungen messen und entscheiden.
Tags und Links asp.net architecture msmq