Queues
| Bezeichnung | Len | | Ist | Max | Count | Error | Wait | Last |
| EIBSendQueue | 5000 | 0 | 265 | 119723 | 0 | 56.80 | 14.12.2007 11:44:22 |
| EIBEmpfQueue | 5000 | 0 | 13 | 182697 | 0 | 1.01 | 14.12.2007 11:44:22 |
| SocketQueue | 100 | 0 | 0 | 0 | 0 | 0.00 | |
| SetWertQueue | 5000 | 0 | 48 | 668425 | 0 | 0.54 | 14.12.2007 11:44:22 |
| BefehlQueue1 | 5000 | 0 | 7 | 32752 | 0 | 0.71 | 14.12.2007 11:44:01 |
| BefehlQueue2 | 5000 | 0 | 8 | 60 | 0 | 6.34 | 14.12.2007 00:00:37 |
| BefehlQueue3 | 5000 | 0 | 0 | 0 | 0 | 0.00 | |
| SichQueue | 15000 | | 0 | 14 | 335654 | 0 | 1.59 | 14.12.2007 11:44:24 |
| EventSendQueue | 1000 | 0 | 0 | 0 | 0 | 0.00 | |
| ServerQueue | 1000 | 0 | 1 | 74111 | 0 | 0.06 | 14.12.2007 11:44:24 |
| ServerQueueEvent | 100 | 0 | 0 | 0 | 0 | 0.00 | |
| ServerQueueList | 100 | 0 | 1 | 10 | 0 | 0.05 | 14.12.2007 11:44:24 |
| ServerQueueHtm | 100 | 0 | 0 | 0 | 0 | 0.00 | |
| ServerQueueHtmBin | 100 | 0 | 0 | 0 | 0 | 0.00 | |
| ServerQueueGUI | 100 | 0 | 1 | 3782 | 0 | 0.06 | 13.12.2007 03:13:42 |
| ServerQueueGUIBin | 100 | 0 | 1 | 37004 | 0 | 0.05 | 13.12.2007 03:13:42 |
| ServerQueueWap | 100 | 0 | 0 | 0 | 0 | 0.00 | |
| ZyklusQueue | 1000 | 0 | 5 | 142171 | 0 | 0.36 | 14.12.2007 11:44:22 |
| KO-Gateway-Queue | 30000 | 0 | 0 | 0 | 0 | 0.00 |
Der Homeserver erledigt nicht alle Aufgaben direkt wenn sie anfallen (synchron). Der Grund hierfür liegt darin, dass eine mögliche Verzögerung bei der Erledigung der Aufgabe den Homeserver ins Stocken bringen würde. So muss z.B. beim Senden eines Telegramms auf den Bus eine Bestätigung vom Empfänger abgewartet werden und beim Ausbleiben dieser oder einer negativen Bestätigung das Telegram erneut gesendet werden.
Deshalb werden solche Aufgaben in eine Warteschlange (Queue) gestellt und warten dort, bis sie von einem dafür verantwortlichen Prozess abgearbeitet werden (asynchron).
Obwohl der Grund für diese Queues darin liegt, den HS nicht ins Stocken zu bringen, so ist paradoxerweise doch dieser Debugseitenabschnitt die erste Anlaufstelle, wenn der Homeserver einmal langsam (viel zu langsam) reagiert. Dieser augenscheinlicher Paradox löst sich aber auf, wenn man sich vor Augen führt, wie eine Warteschlange funktioniert: Neue Aufgaben stellen sich hinten an, und warten bis alle vor Ihnen abgearbeitet sind. Läuft eine Queue also mit sehr vielen Aufgaben voll, dauert es dementsprechend lange, bis die gerade eben eingefügte Aufgabe (z.B. Licht einschalten) abgearbeitet werden kann.
Tabellenspalten
- Len: Länge der Warteschlange, das ist die maximale Anzahl von Aufgaben die in der Warteschlange anstehen können
- Ist: Aktuelle Anzahl von Aufgaben in der Warteschlange. Im Normalfall sind keine oder nur einige wenige Aufträge in einer Queue. Eine grosse Anzahl von Aufgaben über einen längeren Zeitraum in einer Queue ist ein Indiz für ein Problem (z.B. eine Schleife in einer Logik)
- Max: Maximale Anzahl der Aufträge die seit dem booten des HS jemals zusammen in der Warteschlange standen. Ein griosser Wert muss nicht gleichbedeutend mit einem Problem sein. So kann z.B. EINSendQueue einen grossen Max Wert haben da beim starten des HS alle Kommunikationsobjekte die vom Bus gelesen werden sollen zusammen in die Warteschlange gesetzt werden.
- Count: Gesamtanzahl der Aufgaben die seit dem Starten des HS in diese Queue gesetzt wurden
- Error: Anzahl der Fehler in der Queue, wenn z.B. eine Aufgabe nicht angestellt werden kann weil die entsprechende Warteschlange voll ist (Ist=Len)
- Wait: Maximale Zeit die eine Aufgabe bis zu Ihrer Abarbeitung gewartet hat
- Last: Zeitpunkt zu dem die letzte Aufgabe in diese Queue gestellt wurde
EIBSendQueue
Warteschlange der Telegramme die auf den EIB gesendet werden sollen
EIBEmpfQueue
Warteschlange der vom EIB empfangenen Telegramme die darauf warten abgearbeitet zu werden. Z.B. um einen empfangenen Wert in das Kommunikationsobjekt des HS einzutragen.
SocketQueue
SetWertQueue
Warteschlange der internen Zuweisungen von Werten (z.B. Ausgang von Logikblatt) an Kommunikationsobjekte
BefehlQueue1-3
Es gibt im Homeserver 3 Queues die Befehle abarbeiten wie man sie im Logikeditor oder in der Visu auslösen kann. Dies ist ein Unterschied zu den anderen Queuetypen.
In der regel hat jede Aufgabenstellung eine einzige Queue um sicherzustellen dass alle Aufgaben in genau der Reihenfolge abgearbeitet werden in der sie anfallen, dass z.B. das Resultat einer Berechnung nicht vor dem setzten seiner Eingangswerte gesetzt wird.
Bei den Befehlen ist dies etwas anders gelagert weil es sehr viele unterschiedliche Typen von Befehlen gib (z.B Sequenz starten, Webabfrage, Email versenden,…). Einige dieser Befehle können sofort und schnell abgearbeitet werden (Wert in KO setzen), einige dauern etwas länger oder können gar im Fehlerfall sehr lange brauchen (z.B. Webabfrage). Glücklicherweise gibt es keine direkten Abhängigkeiten zwischen den schnellen Befehlstypen und den langsamen. Aus diesem Grund werden alle schnell zu erledigenden Aufgaben (wie „Wert setzen“) in die BefehlQueue1 gesetzt und somit deren Abhängigkeit garantiert während die anderen Befehlstypen je nach Art und Abhängigkeit auf die verbleibenden zwei Queues aufgeteilt werden und somit die Abarbeitungsgeschwindigkeit der ersten Queue nicht beeinträchtigen können.
SichQueue
Die SichQueue speichert alle Schreiboperationen zwischen, bevor sie in den Remanentspeicher geschrieben werden.
EventSendQueue
Queue für die Abarbeitung von Telegrammen aus den Kommunikationsoptionen des HS (IP/EIB-Telegrammes senden/empfangen, Web-Seiten/IP-Geräte abfragen)
ServerQueue
ServerQueueEvent
ServerQueueList
ServerQueueHtm
ServerQueueHtmBin
ServerQueueGUI
ServerQueueGUIBin
ServerQueueWap
ZyklusQueue
KO-Gateway-Queue
