Scheduling-Prioritäten

Die Priorität eines Work-Items ergibt sich aus dem Wert von ExpectedRuntime. Es gibt folgende vordefinierten Prioritäten:

  1. Urgent Work-Items mit dieser Priorität werden immer sofort ausgeführt, ohne Rücksicht auf irgendwelche Ressourcen. Die Maximale Laufzeit beträgt 1 Minute.
  2. Short Diese Work-Items werden mit normaler CPU-Priorität in der Queue für normale Work-Prozesse ausgeführt. Die Maximale Laufzeit beträgt standardmäßig 1 Minute.
  3. Normal Work-Items mit “Normal” werden mit reduzierter CPU-Priorität in der Queue für normale Work-Prozesse ausgeführt. Die Maximale Laufzeit beträgt standardmäßig 15 Minuten.
  4. Long Diese Work-Items werden mit reduzierter CPU-Priorität in einer separaten Queue für Langläufer ausgeführt. Die Maximale Laufzeit beträgt standardmäßig 5 Stunden.

Per Konfigurationsdatei Customer.config auf dem Webserver können die maximalen Ausführungszeiten für die Prioritätsstufen angepasst werden.

Per programmierter Erweiterung von EnumExpectedRuntime können in Projekten zusätzliche Prioritätsstufen geschaffen werden. In den Eigenschaften des Auswahllistenwertes werden die Details angegeben.

Queues und Parallelität

Die Anzahl der gleichzeitig ausgeführten Work-Items (mit Ausnahme Priorität Urgent) ist begrenzt. Es wird eine Feste Anzahl von Work-Prozessen in 2 Queues vorgehalten:

  1. Normal
    In dieser Queue werden nur Work-Items der Prioritäten Short und Normal ausgeführt.
    Standardmäßig ist dafür 1 Worker reserviert.
  2. Langläufer
    Die Queue für Langläufer führt alle Arten von Work-Items (außer Urgent) aus.
    Standardmäßig stehen dafür 2 Worker zur Verfügung.

Der Start der Work-Items erfolgt immer nach Priorität. Wenn also ein Prozess frei ist, wird immer das nächste Short-Item zuerst ausgeführt, auch wenn es ein Platz in der Langläufer-Queue ist. Ein bereits laufendes Work-Item wird aber nicht unterbrochen, um einem höher priorisiertem Work-Item Platz zu machen. Nur durch die Reservierung von Prozessen in der Normal-Queue ist sichergestellt, dass Langläufer nicht alle höher priorisierten Items aufhalten können.

Per Konfigurationsdatei Customer.config auf dem Webserver kann die Anzahl der parallelen Prozesse pro Queue verändert werden.