Performance-Vergleich von Quarz und Pooling mit System-Timer

Question

Wir nähern uns einem sehr häufigen Problem (wir vermuten zumindest), aber überraschenderweise konnten nicht viele Möglichkeiten finden. Für eine Geschäftsanwendung haben wir eine ASP.NET MVC-Anwendung als Upfront-UI-Portal, die mit mehreren MSMQ/Windows-Diensten ausgestattet ist, um schwere Aufgaben auszuführen, z. Synchronisierung mit externen Buchhaltungssystemen.

Wir hoffen, einen neuen Dienst einzuführen, um zeitbasierte Aufgaben auszuführen. Für eine Bestellung im System hat es beispielsweise eine erwartete Warenlieferzeit. Sechs Stunden vor dieser Zeit muss der Service überprüfen, ob wir die Ware erhalten haben oder nicht und entsprechend reagieren.

Wir haben zwei Ansätze:

Ansatz 1: statisch Jobs definieren und basierend auf bestimmten Zeitintervall ausgeführt werden. Jobs können zur Laufzeit mit Hilfe des MEF-Frameworks hinzugefügt/entfernt werden.

Ansatz 2: Führen Sie Quartz.Net als Windows-Dienst und Feed-Task mit seinem Zeitplan über MSMQ aus.

Wir haben einige Ideen, diese beiden Ansätze Pro und Nachteile:

• Effizienz:

Mit Ansatz 1: in dem oben erwähnten Beispiel, es bedeutet, müssen wir alle Kauf nachschlagen Bestellungen und überprüfen Sie alle. Während bei Ansatz 2 nur ein Auftrag für eine Bestellung zu einem bestimmten Zeitpunkt geplant ist.

• Genauigkeit:

Ansatz 1 kaum Genauigkeit und die fehlende Marge ist abhängig von der Zeitintervall-Jobs laufen versichern

• Flexible Zeitplan:

Ansatz 2 könnte bieten sehr flexibler Zeitplan dank seiner Unterstützung für Cron-ähnliche Trigger

• Performance: (dies ist unsere große Unsicherheit)

Wir haben Bedenken für Quartz Bezug auf die Leistung/Stress könnte es tragen, da wir theoretisch Zehntausende von Arbeitsplätzen an den Scheduler werfen könnte.

Unklar über Quarz-Implementierung, wir sind uns jedoch bewusst, dass das Erstellen von Timern nicht ideal (wenn nicht inakzeptabel) für schwere Aufgaben ist.

Q1: Wie verwaltet Quartz eine große Menge an Jobs und feuert sie genau ab, ohne zu viel Overhead durch Timer zu verursachen?

Q2: Könnte jemand Licht auf die Magie unter der Haube werfen? Oder würde sich Quarz verschlechtern, wenn sich Jobs häufen?

Q3: Gibt es einen anderen besseren Ansatz für die Notwendigkeit, die wir haben?

Answer 1

Eine dritte Option besteht darin, eine Datenbank mit anstehenden Jobs zu verwalten. Jeder Datensatz in der Datenbank enthält eine Fälligkeitsdatum, einen Typ und eine ID.Ein (oder mehrere) Arbeiter befragen die Datenbank und greifen (atomar) das nächste fällige (oder überfällige) Element, laden die entsprechende Arbeiterklasse (basierend auf dem Typ) und rufen sie mit der ID auf.

Jede Worker-Aufgabe kann zusätzliche zukünftige Arbeitsaufgaben anstehen, kann sich neu planen, wenn sie nicht ausgeführt werden kann, kann einfach weggehen, wenn sie keine Arbeit mehr hat (vielleicht wurde die ursprüngliche Bestellung gelöscht),. ..

Vorteile:

1. Sie warten überwachen Arbeit/Laufen zu tun/nicht bestanden leicht
2. können Sie fehlgeschlagen Arbeit wiederholen (Arbeit, die begonnen, aber nicht abgeschlossen haben)
3. Sie skalieren Arbeiter leicht herausholen (mehr t Threads oder Prozessoren)
4. Einfach zu konfigurieren (nur eine andere Tabelle)