[Problem] SAS Version 6.00 - curl-Probleme

JL3

Aktives Mitglied
Mitglied seit
4 Dez 2010
Beiträge
1,995
Punkte für Reaktionen
8
Punkte
38
Wie ich schon im Haupttread geschrieben habe, bin ich an der Version 6.00, da die Funktionen Display/Sprachausgabe/Spracherkennung der Version 5.00 nicht wirklich benötigt werden.

Ziel der Version 6.00 ist es, ein schnelleres und damit asynchrones Abarbeiten der psgs zu ermöglichen. Dies soll dadurch erreicht werden, dass die psgs von sasag.php nicht mehr sequentiell sondern gleichzeitig abgearbeitet werden. In der Theorie müsste dies schneller erfolgen und psgs auf langsame Geräte oder Webseiten bremsen dann nicht mehr schnelle evtl. zeitkritische psgs. Soweit die Theorie.

Erster Lösungsansatz: externes curl

Alle psgs werden gleichzeitig mit externem curl gestartet. Klingt gut, habe ich auch umgesetzt, funktioniert auch, ABER bei hundert psgs laufen dann hundert curl-Prozesse und die Himbeere (Pi 2B) geht in die Knie. Bei einer vorher sequentiellen Abarbeitungszeit von 40 Sekunden komme ich so auf 3-4 Minuten. So ist das nicht sinnvoll.

Zeiter Lösungsansatz: internes curl von php

Tests mit curl_multi_exec (Führt die Unter-Verbindungen des cURL-Handles aus) liefern von den psgs nichts Verwertbares zurück. Irgendwie mache ich da einen Denkfehler oder es überfordert den php-Interpreter. :gruebel:

Hat jemand noch eine Idee?
 
Zuletzt bearbeitet:
Moins


Einen Lösungsansatz hab ich jetzt nicht, aber kann es sein dass hier der "Three Stooges Effect" auftritt ?
(Alle Drei wollen gleichzeitig durch die Tür, was misslingen muss)
[video=youtube;gmBj8r1-fDo]https://www.youtube.com/watch?v=gmBj8r1-fDo[/video]
 
Zuletzt bearbeitet:
Ja, das dürfte hinkommen. :)
100 curl-Prozesse auf einmal sind für den Pi dann doch zuviel. Ein neuer Lösungsansatz ist mir bis jetzt auch noch nicht gekommen.
 
Das macht es zwar komplizierter in der Programmierung, aber normalerweise würde man (ich) das mittels "message queues" lösen.

Alle zu startenden Aktivitäten werden in eine Queue gekippt, ggf. noch mit einer Kennzeichnung ihrer Priorität (low, normal, high als grobe Unterteilung). Auf der anderen Seite liest ein weiterer Prozess diese "Aufträge" aus und verteilt sie gemäß ihrer Priorität auf eine begrenzte Anzahl von Worker-Prozessen (womit man dann eben keine 100 curl-Aufrufe parallel hat). Nimmt man dann für jede der Prioritäten z.B. 3 Worker-Threads (+ 1 Manager), bleiben am Ende 10 Prozesse übrig, die trotzdem noch dafür sorgen, daß Aufgaben mit hoher Priorität (und dann hoffentlich kurzer Laufzeit) rasant abgearbeitet werden, während lange laufende Abfragen die schnelleren Aktionen nicht mehr behindern.

So ein Konzept setzt dann allerdings einiges bei den "Aufträgen" voraus, z.B. sollten sie "zustandslos" sein, d.h. sie sollten keine Angaben über zwei Durchläufe hinweg austauschen müssen (bzw. diese Daten müßten bei jeder Auftragserteilung erneut mit gesendet werden und bei jedem Ergebnis wieder zurück, was nicht sehr effektiv ist).

Am einfachsten kann man so ein Konzept umsetzen, wenn wirklich nur eine "Ansage" erforderlich ist, was getan werden soll und das komplette Ergebnis in einer einfachen Antwort übermittelt werden kann (daher auch "message queues", weil es eigentlich nur eine simple "Nachricht" sein soll, die den Auftrag darstellt und das Ergebnis ebenso einfach sein sollte).

Im Prinzip ist so eine Queue ein Puffer bei Funktionsaufrufen in einer service-orientierten Architektur, der keine direkte Synchronisation zwischen Sender und Empfänger erfordert und damit eine asychrone Abarbeitung solcher Anfragen ermöglicht, die dann eben gleichzeitig noch "out of order" erfolgen kann, wenn unterschiedliche Aufrufe unterschiedliche Prioritäten haben (und nach dem "Idealbild" eben auch unabhängig von anderen Aufträgen/Aufrufen sind).

Das ist aber keine Spielerei mehr und auch wenn man sich damit noch andere positive Effekte in die Architektur holen kann (z.B. könnte man die "worker threads" ja auch auf mehrere Geräte verteilen und dann skaliert das gleich wieder besser), ist das erst einmal ein erheblicher Aufwand - aber gerade bei solchen interpretierten Sachen und recht lange laufenden Einzelaufgaben (40 Sekunden sind ja kein Pappenstiel, bei der Anzeige eines eingehenden Anrufs bzw. eines gerade geführten Gespräches dürfte das kaum noch "realtime" sein) wäre so etwas (meiner Meinung nach) ein sinnvolles Konzept, zumal man dann auch bei der Anzeige der Ergebnisse noch mit entsprechenden Prioritäten arbeiten kann und das Ergebnis so eines eingehenden Anrufs eher zu einer Aktualisierung der Anzeige veranlassen sollte als der Wert eines Temperatursensors für einen Raum, der kaum innerhalb von 10 Sekunden signifikante Änderungen erfahren sollte.

Hat man so etwas erst einmal implementiert (vermutlich gibt es sogar entsprechende fertige Lösungen auch in PHP, aber das ist nur geraten), braucht man sich zumindest künftig auch keine Gedanken mehr zu machen, wenn da mal 10-20 weitere Sensoren dazu kommen, die auch etwas länger beim Datensammeln benötigen und man kann eben Sensoren mit 3 Sekunden "Ergebniszeit" wesentlich häufiger abfragen (wenn es notwendig sein sollte, weil der Wert sich auch in solchen Intervallen ändern könnte) als solche mit 10 Sekunden (auch wenn das sicherlich übertrieben große Zeiten sind, die ich jetzt hier ansetze ... 10 Sensoren mit jeweils einer Sekunde für langsam veränderliche Werte sind aber eben bei sequentieller Abarbeitung der Abfragen auch 10 Sekunden).

PS: Ich habe vollkommen vergessen zu betonen, daß ich vom bisherigen Aufbau von SaS eigentlich keine Ahnung habe ... die Annahmen der synchronen Abfrage von "Sensoren" basieren auf der Beschreibung, daß es überhaupt "Runden" mit einer sequentiellen Abarbeitung gibt. Solltest Du also so etwas schon umgesetzt haben (die Unterteilung nach Prioritäten anhand der Geschwindigkeit der Änderung von "Meßwerten" und auch unterschiedliche "Notwendigkeiten" bei der Aktualisierung von Anzeigewerten), vergiß einfach alles bisher Geschriebene ... das ist auch alles nur Theorie und "(versucht) schlau reden" - ich habe mich nicht der Mühe unterzogen, die bisherige Umsetzung in SaS anzusehen (und ich habe vielleicht falsche Schlußfolgerungen aus dem gezogen, was Du als Ziel für die neue Version formuliert hast).
 
@PeterPawn: Der Vorschlag mit der Begrenzung der gleichzeitig simultan ausgeführten Aufgaben ist ein guter Ansatz, den es zu verfolgen gilt. Das von dir dargestellte Konzept gefällt mir. Theoretisch müsste es in den vorhandenen PHP-Code integrierbar sein. Ich denke, da liegt jetzt ein wenig Arbeit vor mir. ;)
 
Der externe curl macht hier immer noch Zeitprobleme. Daher suche ich noch einen anderen Weg. Dauert also noch etwas... :gruebel:
 
Da der externe curl eher verlangsamt als beschleunigt hat, habe ich mich für eine hybride Version entschieden. Somit kann man psgs priorisieren, wenn sie zeitkritisch sind. Solche psgs sind vom Namen her so aufgebaut: psg-ichmusslaufen-.php oder psg-machwas-.php. Die Minuszeichen, die den eigentlichen Namen umschließen, deklarieren es als zeitkritisch und die Ausführung wird wie das Auto-Schalten minütlich per cron gestartet, während die unkritischen psgs nach Abarbeitung sich selbst aufrufend laufen.

@PeterPawn: Nochmal Danke. Der Tipp mit den Prioritäten war hier die Lösung. :)

Die Alpha-Version läuft bei mir gerade im Test, die Beta folgt bald. ;)
 

Neueste Beiträge

Statistik des Forums

Themen
244,691
Beiträge
2,216,605
Mitglieder
371,308
Neuestes Mitglied
Chrischan 79
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.