Multithread-Datenbankzugriff (.NET)

Question

Ich bin gerade dabei, eine App zu entwickeln, die Zitate generiert. Die Gesamtzeit für die Erstellung aller Angebote beträgt etwa 10 Sekunden und bietet derzeit eine inakzeptable Benutzererfahrung.

Ich möchte jedes Zitat mit mehreren Threads versehen, damit der Benutzer die Ergebnisse sehen kann, sobald sie eintreffen. Das Problem ist, dass die app, die ich geerbt habe, eine Menge von Bus-Logik auf die DB tut.

Was ich mich frage ist, wenn es ok ist, jedes Zitat Element zu multithreading, oder würde dies zu viel Last auf dem DB-Server (z.B. 5 Zitate = 5 Threads, oder Threadqueueworkeritems) verursachen?

Answer 1

Auf den meisten RDBMS sollten 5 gleichzeitige Verbindungen kein Problem sein, also denke ich, dass Sie leicht fünf Threads haben können, von denen jeder seine eigene Verbindung verwendet

Answer 2

Datenbanken sind in der Regel für die Verarbeitung mehrerer gleichzeitiger Verbindungen ausgelegt. Sie brauchen sich also keine Sorgen zu machen.

Answer 3

Das Einzige, worüber ich mir Sorgen machen würde, ist die Frage, was das "Erstellen eines Angebots" in der DB bedeutet. Dies kann das Schreiben in die Datenbank und wenn Sie eine Menge von Transaktionsaktivität in dort haben, können die verschiedenen Angebote miteinander konkurrieren und könnte am Ende mit Zitaten kommen in Serie aufgrund von Blockierung oder schlimmer noch, Deadlocking.

Ausgehend von den spärlichen Angaben in der Frage handelt es sich jedoch um ein Worst-Case-Szenario.

Answer 4

Es sollte keine Probleme mit der Datenbankbelastung geben. Allerdings sollten Sie den Code auf Deadlock-Bedingungen überprüfen, die Sie mit größerer Wahrscheinlichkeit finden, wenn Sie anfangen, Dinge parallel laufen zu lassen. Außerdem müssen Ihre Transaktionsgrenzen gut definiert sein, aber wenn dies ein Zitat erzeugt, würde ich mir nicht vorstellen, dass ReadUncommitted ein Problem sein würde