Ressourcenzuteilung / -verwaltung von PHP-Servern

[Antoras]

Hallo,

ich würde mal gerne etwas über die Ressourcenzuteilung / -verwaltung von mit PHP-bearbeitenden Requests wissen:

Bei PHP ist es doch so, dass jeder Request vom Server praktisch eine eigene Instanz zugewiesen bekommt, oder? Also, dass die Requests unabhängig voneinander Ressourcen zur Verfügung gestellt bekommen ganz im Gegensatz zu z.B. Java, wo man eher darauf schaut, dass wenige bis nur eine Instanz gleichzeitig von einem Objekt existieren und die Webapp nach dem Response weiterhin im RAM bestehen bleibt. Stimmt das so in der Art, oder kann man das in PHP auch so programmieren, dass sich die Requests ein und dieselbe Ressource teilen? Da würde mich dann auch interessieren ob die einzelnen Requests direkt miteinander kommunizieren können, oder ob der Datenaustausch nur über eine Persistenzschicht möglich ist.

Ich würde mich freuen wenn mir da jemand was drüber sagen könnte.

 

[Wessy]

Hallo Antoras und herzlich willkommen(?),

vielleicht wäre hier die Antwort eines Web-Serveradmin besser, aber ich kann dir zumindest ein paar Sachen darüber erklären. Zum einen: Einen PHP-Server ansich gibt es nicht. Was du vermutlich meinst ist ein Web-Server wie z.B. Apache mit PHP-Modul (umgangssprachlich PHP-Server ). Aber es ist wichtig zu verstehen, dass PHP als Modul läuft (immerhin kann auf einem Webserver z.B. ASP,PHP,Perl,Java parallel laufen).

Wenn ein Client eine Anfrage an den Server stellt, so verarbeitet der Server die Datei, welche er mit dem Request assoziiert. Z.B. http:\\Server\ordner\ lässt den Server (je nach Konfiguration) die Datei \root\ordner\index.html laden. Diese wird dann interpretiert und an den Stellen wo (je nach Konfiguration des Servers) <?php steht, springt der PHP-Interpreter (bis ?>) ein und verarbeitet die Informationen für den Web-Server zur Rücksendung an den Client. Wenn die Datei index.html bis zum Schluss abgearbeitet wurde, so werden alle PHP-Variablen durch den PHP-Garbage-Collector wieder freigegeben. Somit ist alles was dieses Modul angeht flüchtig und nur für die 10tel Sekunde der Verarbeitung verfügbar.

Eine andere Speicherstelle ist unabdingbar. Hier gibt es z.B. Datenbanken (MySQL, OracleXE, Postgre, etc) oder z.B. Sessions. Sessions sind serverseitige Cookies welche über eine definierte Dauer bestehen (in serialisierter Form) und vom PHP-Sessionhandler bei Bedarf zur Verfügung gestellt werden. Theoretisch kann man solche Sessions für alle Request's auf ein und dasselbe Cookie setzen wovon ich persönlich jedoch dringendst abraten würde.
Meine Wahl wäre eine Datenbank. Ich hoffe ein paar Fragen wurden beantwortet. Grüße Wessy.

 

[Antoras]

Hallo Antoras und herzlich willkommen(?),

Hab mich vor längerer Zeit mal registriert. War aber bisher nur in anderen Foren aktiv. Ich Programmiere jetzt dann doch schon etwas länger, mir waren deine hier aufgeführten Punkte dann doch schon bekannt. Hätte ich in meinem ersten Beitrag hinschreiben sollen. Hab bisher mit PHP nur noch nicht besonders viel gemacht. Sry für die Verwirrung.

Einen PHP-Server ansich gibt es nicht.

Meinte den Webserver auf dem PHP läuft. Hab mich verschrieben.

Somit ist alles was dieses Modul angeht flüchtig und nur für die 10tel Sekunde der Verarbeitung verfügbar.

Mich hatte hier mehr interessiert was passiert wenn mehrere Anfragen gleichzeitig auf ein Skript zugreifen. Weil darauf zielte meine Frage mit der Kommunikation aus. Wenn in dem Fall die Ressourcen auch mehrmals allokiert werden, dann gestaltet sich eine Kommunikation nämlich äußerst schwierig. Und da wollte ich wissen ob man das z.B. mit einer DB in den Griff bekommen kann, auf dessen Ressourcen die Skriptinstanzen eben zugreifen müssten, wenn sie miteinander kommunizieren wollen.
Wobei ich mir gut vorstellen kann, dass wenn man will, dass Anfragen untereinander kommunizieren, man dann höchstwahrscheinlich auch kein PHP nimmt.

Meine Wahl wäre eine Datenbank.

In Java würde ich Sessions im RAM verwalten. Aber ist in PHP ja schwierig, da die Ressourcen wieder freigegeben werden.

 

[saftmeister]

PHP kennt auch Sessions. Die werden allerdings nicht wie bei einem Applikation Server wie JBoss als Beans implementiert sondern beim Abbauen der HTTP-Verbindung ins Dateisystem serialisiert. HTTP-Anfragen können untereinander nicht wirklich kommunizieren. Das bietet das Protokoll nicht an.

Zum Thema Datenbank-Zugriff. Wenn die Datenbank das anbietet und die Client-API es unterstützt, kann eine Datenbank-Connection in PHP auch persistent sein. Als Beispiel verwendet man dann statt mysql_connect() eben mysql_pconnect().

Wenn du aber Java-geschädigt bist (;-)), solltest du vielleicht ohnehin mit einem Framework anfangen. Nur als Idee. Es gibt da eine Menge schöner Frameworks, die dich dann schon fast wie "zu Hause" fühlen lassen. Wie auch in Java hat da jedes seine Stärken und Schwächen. Ich verwende beispielsweise Zend Framework.

 

[Wessy]

Ich bin mir zwar noch nicht ganz sicher ob wir beide das selbe meinen, aber: Wenn du so etwas meinst wie PIPE's bei Windows (also zwei Prozesse die miteinander direkt kommunizieren) muss ich dich enttäuschen. Dies ist bei mit PHP (in der Standardkonfiguration) difinitiv nicht möglich. Evtl findest du mit CGI noch eine Möglichkeit. Da bin ich allerdings gar nicht fit drin.

Oder erklär noch mal was wofür genau benötigt wird bzw. um welches Szenario es sich dreht. Bei parallelen Anfragen an einen Webserver kann ich auf jeden Fall sagen, dass parallel nur pseudo-parallel bedeutet. Die erste Anfrage z.B. blockiert bei INSERT/UPDATE/etc-Anfragen die Tabelle für Änderungen, SELECT/SHOW/etc-Anfragen hingegen können pseudo-parallel abgearbeitet werden. Bei einer kurzzeitigen Sperrung einer Tabelle werden folgende Änderungen nach FIFO weiter verarbeitet.

 

[Antoras]

@saftmeister
Ich hab mich bei Requests nicht unbedingt auf HTTP bezogen, sondern eher auf Protokolle, die z.B. von Sockets benutzt werden. Stichwort Spiele. Es macht ja wohl nicht viel Sinn einen Gameserver in PHP zu programmieren. Erstens wegen der Performance und zweitens, weil die Daten ja bei jedem Request serialisiert werden müssen.

Wenn du so etwas meinst wie PIPE's bei Windows (also zwei Prozesse die miteinander direkt kommunizieren) muss ich dich enttäuschen. Dies ist bei mit PHP (in der Standardkonfiguration) difinitiv nicht möglich. Evtl findest du mit CGI noch eine Möglichkeit. Da bin ich allerdings gar nicht fit drin.

Pipes mein ich nicht direkt, eher die Kommunikation zwischen Threads, die im gleichen Prozess ablaufen. Weil, der Webserver wird ja nicht für jeden Request einen eigenen Prozess, sondern wohl eher Threads aufmachen. Aber wenn es bei Pipes keine Kommunikationsmöglichkeiten gibt, dann höchstwahrscheinlich wohl auch nicht bei Threads.

Brauchen tu ich das momentan nicht, mich hätte es einfach nur mal interessiert.

 

[saftmeister]

Ok, du bringst da ein paar Dinge durcheinander.

1. HTTP verwendet natürlich auch Sockets. Ein Socket is ja nur die End-zu-End-Verbindung zwischen Client und Server. Was über das Socket an Informationen fließen, bestimmt das Protokoll.
2. Wenn du mit Requests den Zustand meinst, das ein Client ohne ein wohl-definiertes Protokoll wie z.B. RMI oder HTTP kommuniziert also quasi "plain", musst du dich als Entwickler um die Persistenz sowie die Session selbst kümmern - in jeder Sprache.

In PHP ist es übrigens egal, welches Transport-Protokoll verwendet wird. Sessions sind immer über den gleichen Mechanismus verfügbar. Eine Session hat ja zunächst einmal nichts mit HTTP zu tun sondern behebt nur den Misstand, das HTTP sich keine Zustände merken kann. Das Gegenstück (im Browser persistierte Informationen) sind Cookies.

Den Umstand, eine Session auf und abzubauen, sobald ein Client sich (dis-)connected hast du in jeder Sprache. Die dabei benötigten Ressourcen sollten in etwa auch die gleichen sein.

Hast du eine Verbindung, die nicht geschlossen wird (also das Gegenteil von HTTP), bräuchtest (igitt Konjunktiv) du gar keine Session. Lediglich eine reguläre Persistenz.

Und ja, es ist Möglich einen Service in PHP zu schreiben, genauso wie das in Perl, C/++ oder Java auch möglich ist.

Vom Ressourcen-Hunger würde ich PHP sogar eher zwischen C und C++ bzw. Perl anordnen. Dann erst kommt Java.

 

[saftmeister]

Pipes mein ich nicht direkt, eher die Kommunikation zwischen Threads, die im gleichen Prozess ablaufen. Weil, der Webserver wird ja nicht für jeden Request einen eigenen Prozess, sondern wohl eher Threads aufmachen. Aber wenn es bei Pipes keine Kommunikationsmöglichkeiten gibt, dann höchstwahrscheinlich wohl auch nicht bei Threads.

Du suchst wohl eher sowas wie IPC/SEM/Shared Memory.