Response Cachen, Concurrency, memcached?

port29

deus.Server
Hallo Leute,

ich brauche mal einen Tipp für die Umsetzung. Ich habe eine SPS, mit der ich per phpModbus kommuniziere. Genauer gesagt:

Per asynchronem http Request wird ein PHP Script aufgerufen, das per Modbus 1kbit Daten aus der SPS ausliest und diese dem Script zur weiteren Bearbeitung stellt. Dieses Script soll nun ein Mal pro Sekunde oder alle zwei Sekunden - jedenfalls in einer sehr kurzen Zeitspanne immer wieder laufen, um aktuelle Daten zu bekommen. Wenn ein Rechner auf das Script zugreift, ist alles kein Problem. Wenn es zwei sind, dann ist es auch kein Problem. Wenn es 10 Rechner sind, dann lastet es die SPS schon relativ stark aus. Und das darf einfach nicht sein. Ich möchte deshalb die antworten irgendwo zwischenspeichern.

Meine Frage wäre jetzt, wie ich das machen kann. Woran ich momentan denke, ist memcached. Allerdings weiß ich nicht, wie dort der Umgang mit Cuncurrency ist (Prozess 1 schreibt, Prozess 2 liest). Und auch PHP und Cuncurrency.

Kann mir da jemand evtl. weiterhelfen oder einen anderen Ansatz als memcached nennen?
 
Kannst du nicht einfach ein Script schreiben, welches jede eins bis zwei Sekunden die SPS ausliest und dieses in eine Datei / DB schreibt?

Die Clienten lesen dann einfach alle X Sekunden diese DB / Datei.

So greift nur dein Server (Client für die SPS) auf die SPS zu und die Clients bleiben auf dem Server..

paD
 
Bei der Datei gibt es das klassische Concurrency Problem. Was passiert, wenn die Werte aus einer Datei ausgelesen werden, bevor diese Datei fertiggeschrieben wurde. So liest ein Prozess eine unfertige Datei aus. Bei Datenbanken kann ich evtl. die Tabellen locken, bevor ich da etwas reinschreibe. Das würde inkonsistente Datensätze verhindern. Allerdings halte ich es für ein Overkill jetzt jede Sekunde schreibend auf die Festplatte zuzugreifen. Deshalb war die Idee mit memcached, also einer Datenbank mit Schlüsseln, die nur im Speicher existent ist und es egal ist, ob die Werte verloren gehen oder nicht.

Es ist leider alles nicht so ganz einfach, wie man es sich vorstellt...
 
was ist an der datenbank das problem?
Ein daemon laufen lassen, der ständig die daten da reinschreibt. (Brauchst auch nichts locken, da dieses Programm ja das einzige ist, das Modifikationen der Datenbank vornimmt)
Auslesevorgang ist für ne datenbank natürlich (auch quanitativ gesehen) kein Problem.
 
was ist an der datenbank das problem?

Ein Daemon scheidet schonmal aus. Wenn ich keine aktuellen Werte brauche, dann brauche ich auch kein Programm, das ständig im Hintergrund läuft und Werte abfragt.

Eine andere Geschichte ist eine Datenbank. Du fragst, was das Problem bei einer Datenbank ist. Was ist für dich eine Datenbank? Nenn mal ein Produkt und wie du die Werte in einer Datenbank speichern und abfragen würdest, dann nenne ich dir die Probleme.
 
Ähm, die Argumentation warum ein Daemon aussscheidet erschließt sich mir nicht so ganz? Wie kommst du sonst an die daten alle 1-2 Sekunden?

Ich würde als Datenbank MySQL benutzen und die über den PHP-Adapter PDO befüllen und auslesen.

Natürlich hört sich diese zusätzliche zwischenspeicherung sehr umständlich an, aber anders scheint es ja nunmal nicht zu gehen, wie dein versuch zeigte, die Daten driekt abzuholen.
 
Die CPU einer SPS ist dauernd zu 100% ausgelastet. Sie macht keine Pause. Sobald ein Programmzyklus durchgelaufen ist, fängt ein neuer von vorne an. Wenn jetzt noch zusätzlich eine Abfrage vom Script kommt, dann läuft das eigentliche SPS Programm eben langsamer. Und langsamer bedeutet, dass sehr kurze Impulse einfach nicht mehr erfasst werden können. Sicher gibt es auch da Kontrollstrukturen, aber auf die möchte ich nicht zurückgreifen. Wenn jetzt kein einziger Client die Werte von der SPS braucht, wieso soll ich dann das Programm unnötigerweise verlangsamen, in dem ich einfach zyklisch jede 1-2 Sekunden die Werte abfrage?

Ich sehe deshalb nur die Möglichkeit, das ganze per Script abzuwickeln und zwar so:
1) Gibt es irgendwo schon den Wert, dann gehe zu 4)
2) Wert von der SPS abrufen
3) Wert für weitere Clients zwischenspeichern
4) Wert an den Client senden

Nehmen wir jetzt mal MySQL als dein Beispiel an und nehmen mal 10 Clients. Die Wahrscheinlichkeit ist da sehr groß, dass zwei Clients zur gleichen Zeit auf die Datenbank zugreifen und feststellen, dass es dort keinen aktuellen Wert gibt und dann beide neue Werte aus der SPS auslesen. Und MySQL wird mit log N immer langsamer, sowohl beim Suchen als auch beim Eintragen der Werte in den Index.

Ein weiteres Problem dürfte die Architektur sein. Bei einer mechanischen Festplatte habe ich kein Problem damit, jede Sekunde mal auf die Platte schreibend und lesend zuzugreifen. Aber bei einer SSD oder noch schlimmer bei einer CF/SD habe ich irgendwann einfach defekte Sektoren.
 
Zurück