Belastung mit php Skripts

Moin, ich lese mit einem php Skript die q3d Daten meins Zählers aus. Der liefert den ganzen Schwung im Sekundentakt, kommt also schon ganz schön was rein.

Wenn ich das über nen Cutter+RegVar mitschneide, steigt meine CPU-Last gleich so um 20%. Lasse ich das Skript als Daemon laufen (direkt mit dem php Interpreter), dann steigt die Last kaum an - allerdings braucht es dann ganz schöne Klimmzüge, um die Daten in IPS zu bekommen.

Wie bekomme ich das in IPS hin, ohne die CPU so zu belasten ? Bringt es von der Performance etwas, daraus ein Modul zu machen ? Oder wie macht man das ?

HI wie und welchen Bus ( ModBus MBUS usw. ) hat den der Stromzähler ?

Dass die PHP Skripte die CPU sehr beanspruchen ist leider noch ein bekanntes Problem. Nall Chan hatte dies bzgl. seiner PHP Module bereits bemängelt. Zur Zeit gibt es leider keine Lösung/Workaround dafür.

paresy

Aktuell glaube ich nicht das du mit einem Modul besser fährst.
Siehe Bug und Systemlast hier:
IP-Symcon Community Forum

IP-Symcon Community Forum

Und um eine RegVar um Daten zu buffern wirst du wohl auch nicht rumkommen. Da jeder Empfang von Daten über eine IO-Instanz(IPS) eine Instanz(PHP) von deinem Modul erzeugt und nach Abarbeitung wieder zerstört. Du kannst also keine Daten im Modul vorhalten/buffern.

Oder den Cutter lassen, so dass dein Modul pro Datensatz der aus dem Cutter kommt einmal durchlaufen wird.

Michael, der zu langsam war :slight_smile:

Könntest nicht den Cutter als Buffer missbrauchen ?
Ich meine die Daten erst dann weitergeben wenn eine gewisse Sampleanzahl (Buffer Größe) erreicht ist.
Hinterher dann im Script so viele überflüssigen Daten wegwerfen so das noch eine sinnvolle Auflösung entsteht.

gruß
bb

Der Cutter ist ja sogar ein Buffer. Er hält den ‚Rest‘ bis er wieder Daten zusammen hat zum weitergeben.
Daten nicht zu verarbeiten (also einfach weg zu werfen) macht bei einigen Protokollen keinen Sinn.
Sobald du einmal aus den Sync bist, musst du ja den Einsprung wieder schaffen. Das jedes mal per Absicht zu machen ist etwas unschön.
Aber dabei kommt mir gerade eine Idee für einen Funktionswunsch. :smiley:
Michael

Ah, schade. Es ist ein Client Socket, der über einen Yport die Daten des q3d Zählers bekommt. Ich werde dann wohl bei dem Daemon bleiben - wenn ich da die Daten per json rüberschubse, geht das eigentlich ja auch.

Brauchst Du die Daten denn in dem kurzen Intervall? Wenn nicht öffne und schliesse doch den Socket in dem Intervall, in dem Du aktualisierte Daten haben möchtest.

Geht aktuell ja auch nicht. Da ist noch der open/close Bug :stuck_out_tongue:

Super. Ein Bug verhindet einen Bug zu umgehen. :smiley:

Hallo Nall chan.

Kannst Du gelegendlich meinen WalkAround prüfen, ob er bei dir ebenfalls zuverlässig funktioniert.

https://www.symcon.de/forum/threads/27779-CSCK_SetOpen-%28noch%29-nicht-vorhanden?p=256041#post256041

Gruß
lueralba

Ja und dann doch Jein… und noch mal Nein. :smiley:

  1. Fall (Ja)
    Ich sende mit einer Instanz exclusiv über ein I/O.
    Dann könnte ich jedesmal die IO-Instanz vorher öffnen und dann schließen.

  2. Fall (Jein)
    Multiple Instanzen senden über ein I/O.
    Ich müßte das senden über eine Semaphore serialisieren. Aufwändig aber könnte gehen.
    Allerdings ist dann das öffnen und schließen auch eine ünnötige Verzögerung, ebenso wie die Semaphore.

  3. Fall (Nein)
    Multiple Instanzen senden und empfangen über ein I/O.
    Die IO-Instanz muss offen bleiben, weil sonst könnte ich auf eintreffende Daten nicht reagieren.

Fall 2 könnte ich bei meinem ELRO Modul mal testen.

Fall 3 gilt für alle meine HM-Erweiterungen, da ich Events aus dem HM-Socket brauche.
Ich kann ja schlecht den HM-Socket schließen :rolleyes:

Ich hoffe und bettel das Paresy hier eine dauerhafte Zukunftsichere Lösung findet.
Aktuell sind die PHP-Module kein Ersatz für das alte Delphi SDK.
Gerade Fall 3 war dort überhaupt kein Problem.

Michael