Zitat von
Stefan Hueg:
Es gibt eine Property namens "Scheduler" bei der
Indy TCP Server Komponente. Nur was genau ist das?
HI,
soetwas wie einen Scheduler findest du häufiger dort, wo parallel mehrere Prozesse laufen. Das einfachste Beispiel wäre hier so ziemlich jedes (große) Betriebssystem, insbesondere natürlich solche mit grafischer Oberfläche. Hier besitzt das Betriebssystem als einzigstes den Zugriff auf die CPU. Der Scheduler weißt nun allen aktiven Prozessen Rechenzeit zu und da man i.d.R. weniger Prozessorkerne als laufende Prozesse hat, verteilt der Scheduler somit die tatsächliche Rechenzeit auf transparent auf die laufenden Prozesse. Diese merken das natürlich nicht.
Wichtig ist dabei, dass der Scheduler hier auch Prioritäten setzen kann. Es gibt gewisse Prozesse, die sollten nie warten und immer sofort ausgeführt werden, andere können ohne Probleme zurückgestellt werden. Im besten Fall wird die CPU optimal genutzt und der Benutzer merkt gar nichts vom Scheduler (ausser das alles läuft).
Bei einem Server hat man wiederum ein ähnliches Problem, es können quasi-parallel Anfragen eintreffen. Natürlich wird hier kein Server eine Anfrage komplett abarbeiten und erst dann die nächste Anfrage annehmen. Vielmehr wird auch hier versucht die Anfragen parallel abzuarbeiten. Würde man hier für jede Anfrage einen eigenen Systemprozess verwenden, dürfte klar sein dass hier schnell eine Unmenge solcher Prozesse existiert. Die Synchronisation und die Prioritäten nun vom
OS verwalten zu lassen kann dabei dann ganz schön viel Zeit kosten. Vorallem ist man auch auf die vom
OS zur Verfügung gestellten Möglichkeiten beschränkt. Hier kann es durchaus sein, dass man mehr Prioritätsstufen unterscheiden möchte, dass man Ack-Pakete immer so schnell wie möglich verschicken möchte usw.
Deswegen bietet
Indy einfach die Möglichkeit die Jobs durch einen eigenen Scheduler zu verwalten. Der Scheduler bekommt dabei vom
OS Rechenzeit und verteilt diese auf die aktiven
Indy Jobs. Intern wird dann z.B. beim Threadbasierten Scheduler ein Threadpool verwendet. Das ist dann einfach eine Menge von Threads, die frühzeitig erzeugt und gespeichert werden. Nur diese Threads arbeiten Jobs ab. Das heißt, dass man nicht für jede Anfrage einen eigenen Thread bereitstellen muss, was zwei Vorteile mit sich bringt:
- Der Thread muss nicht erzeugt werden, spart eine Menge an Zeit!
- Dadurch dass die Anzahl der Threads begrenzt ist, kommt es hier nicht zu einer totalen Auslastung des OS für die Verwaltung der Threads (jeder Thread würde nur minimale Rechenzeit bekommen und ewig brauchen bis er fertig ist)
Ich hoffe die Idee ist grob (und weniger wirr als in der Hilfe) klar geworden.
Gruß Der Unwissende