Meine Frage bezieht sich auf die Performance der Telnet-Implementierung auf FTL-Seite. Wenn ich die Schnittstelle mit einer Parallelität von 1 abfrage passt alles wunderbar.
Wenn die Parallelität >1 ist (also mehrere Abfragen gleichzeitig gegen die Telnet-Schnittstelle), kommt es vor, dass einige (unterschiedliche) Abfragen, manchmal, in einen Read-Timeout rennen (ich habe die Telnet-Implementierung selbst vorgenommen, daher kann ich ziemlich genau sagen, dass der Request geschrieben wird, aber der Response nicht mehr zurückkommt). Der Read-Timeout liegt bei 5 Sekunden.
Seit FTL 5.3.1 sehe ich, dass die durchschnittliche Response-Zeit der Telnetschnittstelle bei 5-10ms liegt, sie ist zur letzten FTL Version erheblich beschleunigt.
Meine Frage ist jetzt:
Unterstützt FTL grundsätzlich parallele Anfragen an die Telnet-Schnittstelle?
Wenn ihr jetzt sagt, nee, lieber nicht, würde ich dass auf meiner Projektseite so vermerken.
Ja, es wird unterstützt, auch wenn es nie so vorgesehen war und keine Geschwindigkeitsvorteile mit sich bringt. Intern läuft eine Kette von if-Bedingungen über die ankommenden Befehle und steuert entsprechend Kommandos ein, die dann jeweils eine Antwort liefert. Es ist nicht garantiert, dass die Antworten in der gleichen Reihenfolge kommen wie die Anfragen gestellt wurden:
Eigentlich wollten wir die Telnet-Schnittstelle nach außen gar nicht groß beschreiben, sondern nur zur Kommunikation mit PHP benutzen. Der geplante Verwendungszweck ist es eine Verbindung aufzubauen, ein Kommando zu senden, die Antwort zu lesen (bis zum Marker ---EOM---) und dann die nächste Anfrage zu senden, etc.
Es ist auch möglich mehrere Verbindungen parallel zu öffnen, die dann jeweils eine Anfrage abarbeiten. Das sollte jedoch nicht schneller sein, da wir nicht zwischen Schreib. und Lesezugriff auf die Daten unterscheiden und die Aufrufe daher gegenseitig aufeinander warten müssen.
Ich sollte dann wohl auch anmerken, dass wir derzeit für Pi-hole v6.0 an einem kompletten API Redesign arbeiten. Telnet wird dann komplett verschwinden. Es passt mehr in eine Zeit vor 6 Jahren, wo fast sämtliche Berechnungen noch in PHP abliefen und daher eh langsam waren und Pi-hole gefühlt noch unter zehn Nutzern haben. Die neue API wird eine auf dem REST-Paradigma basierende JSON-Schnittstelle werden, die programmatisch einfacher zu handhaben sein wird.
Hi DL6ER,
vielen Dank für Deine Erklärung. Dann verwundert mich das umso mehr.
Ich habe heute mal (seit 10:00) die Parallelität meiner Anwendung auf 1 runter gesetzt (also keine Parallelität, alle Requests gehen nacheinander an den PiHole).
Die fehlgeschlagenen Requests visualisiere ich mit Grafana und man kann sehen dass auch ohne Parallelität, manchmal, verschiedene Methoden kein Ergebnis zurückliefern.
Was mich umso mehr erstaunt ist, dass Pihole davor / danach mit 1-2ms Responsezeit antwortet.
Ich bin zu wenig in die Speicherung der Werte in FTL involviert, aber kannst Du mir vielleicht sagen ob es zu einer Locking-Situation kommen kann?
Soll heißen, wenn ich die Daten versuchte zu lesen während gerade Werte geschrieben werden könnte ein Lock dafür sorgen dass der Response nicht mehr zurück kommt. Oder sowas.
In FTL-Log / Pihole-Log sehe ich zumindest keinerlei Fehler die auf eine Fehlfunktion schließen lassen.
Mein System würde ich mal ausschließen.
Das läuft zwar alles auf einem Rechner (alles als Docker-Container).
Auf Ubuntu Server mit 24 Cores und 64 GB RAM.
Ah und vielen Dank für Deine Ausführung bezgl. der zukünftigen Version von PiHole.
Ich werde dann schon mal anfangen meinen Code umzubauen.
Machts für mich viel einfacher JSON-konforme TOs zu handeln als Strings mit Regex auseinander zu fuddeln.
Der Rest bleibt ja wie gehabt nur das ich das Telnet-Interface austausche.
Das sollte eigentlich ausgeschlossen sein. Wenn mehrere Anfrage ankommen, müssen die alle ein Barrier über-/durchqueren. Wenn gerade ein Prozess eine Lock hat, müssen die anderen hier warten und dürfen dann nach und nach dran kommen. Mir ist es noch nie passiert, dass einzelne Anfragen ohne Antwort zurück kamen.
Ich denke auch, dass uns das aufgefallen wäre, denn dann würden bei vielen Leuten jeweils Inhalte auf dem Web Interface fehlen, denn es gibt da keine Retry-On-Error bzw, Retry-On-EmptyResult Regeln.
Kannst Du das manuell (= per Terminal) provozieren? Also z.B. mit mehreren
Hihi,
was für ein Fehler!
Bei mir!
Was das Programm bislang getan hat:
Solange der Netzwerkstream Daten bekommt lese ich die aus (in einer while-Schleife, solange TcpConnection.read einen Wert >0 zurückliefert).
Und zwar in ein Array[byte] mit der Länge 256.
Dieses Ding wandle ich ein eine Variable vom String (nennen wir sie mal tmp) und füge das einem Stringbuilder hinzu.
Danach prüfe ich ob tmp die Zeichenkette ---EOM--- enthält und breche ab.
Weil ansonsten der Netzwerkstream nicht weiß, dass keine fachlichen Daten mehr kommen und ewig offen bliebe.
Das funktioniert oft.
Ich habe aber nicht bedacht das:
Bsp:
Ende vorletztes Array (um es besser lesen zu können als String): [reply_CNAME 2988\nreply_IP 6759\nprivacy_level 0\nstatus enabled\n---E]
Anfang letztes Array: [OM---\0\0\0\0\0....]
Ich hoffe Du siehst was ich meine?
Dadurch schlägt natürlich die Stringprüfung auf die umgewandelten Teilstrings fehl, weil weder ---E noch OM--- passt nicht auf contains(---EOM---).
Meine funktionalen Tests können das natürlich nicht abdecken.
Das wäre eher was für Integrationstests, nunja, wenn ich Zeit habe.
Mit JSON wäre das nicht passiert.
Aber so weiß ich wenigstens wie es zukünftig weiter geht mit dem Projekt.
Kannst Du was über einen möglichen Zeitrahmen sagen? Dann würde ich das Telnet Projekt in einem deprecated Branch umziehen und den Master Branch mit REST-API weiter entwickeln.
Je nachdem was Euer Zeitrahmen so hergibt.
Leider nein. Der Stand ist - üwrde ich mal sagen - ca. 20% fertig, aber derzeit bin ich der einzige, der daran arbeitet. Mit noch zahlreichen Nebenbaustellen, gerade auch im Privatleben, hängt das leider immer hinten an. Ob das nun März 2021 wird oder eher Oktober ... da lässt sich nichts verlässliches zu sagen.
