Benutzt PHP mehrere Threads?

[Noooooooooos]

Hi miteinander...

Ich habe eine Seite, welche Daten einer mysql-Datenbank mit PHP ausgibt. Ich frage mich jetzt wie der PHP-Server arbeitet. Liefert er eine Anfrage/Seite nach der Anderen aus, oder gibt es da mehrere Threads, welche parallel abgearbeitet werden?

Denn, da meine mysql-Datenbank nur vom PHP-Server benutzt wird, hängt von dessen Verhalten ab, ob ich meine mysql-Abfragen mit locks schützen muss.

Im Fall, dass der Server parallel arbeitet, ist eine serielle Verarbeitung erzwingbar? Ist das überhaupt eine Option?

Gruss
Noooooooooooos

[dedlfix]

Hi!

Ich frage mich jetzt wie der PHP-Server arbeitet. Liefert er eine Anfrage/Seite nach der Anderen aus, oder gibt es da mehrere Threads, welche parallel abgearbeitet werden?

PHP ist üblicherweise kein egienständiger Server sondern wird vom Webserver aus aufgerufen. Und da musst du schauen, wie dein Webserver konfiguriert ist.

Denn, da meine mysql-Datenbank nur vom PHP-Server benutzt wird, hängt von dessen Verhalten ab, ob ich meine mysql-Abfragen mit locks schützen muss.

Warum willst du Locks verwenden? Hast du keine Transaktionen zur Verfügung? Für das Bearbeiten einzelner Datensätze unabhängig von anderen braucht man kein Locking, das macht das MySQL von selbst. Auch das Verwenden von auto_increment und das Weiterverarbeiten des generierten Wertes ist gefahrlos möglich.

Im Fall, dass der Server parallel arbeitet, ist eine serielle Verarbeitung erzwingbar? Ist das überhaupt eine Option?

Davon ist mir nichts bekannt. Für welches Szenario?

Lo!

[Nooooooooooos]

Danke für deine Antwort.

Dann kann man also beim Server einstellen, ob er PHP-Anfragen seriell oder parallel bearbeiten lässt. Wo müsste ich bei Apache suchen für diese Einstellungen?

Meine andere Frage ist, ob man das überhaupt darf, oder ob ich dann irgendwo schwerwiegende Nachteile auftauchen. Ich schätze mal, dass pro Sekunde höchstens etwa 5 Anfragen kommen könnten.

Transaktionen sind keine Option, da ich zwischen den einzelnen Statements Berechnungen mit PHP durchführen muss.

Gruss
Nooooooooooooos

[Jens Holzkämper]

Tach,

Meine andere Frage ist, ob man das überhaupt darf, oder ob ich dann irgendwo schwerwiegende Nachteile auftauchen. Ich schätze mal, dass pro Sekunde höchstens etwa 5 Anfragen kommen könnten.

ich habe das Gefühl, du hast ein Konzeptproblem, denke dran, auch wenn der Apache nicht threaded läuft (in Kombination mit PHP ist das eher selten), laufen mehrere Prozesse parallel.

Transaktionen sind keine Option, da ich zwischen den einzelnen Statements Berechnungen mit PHP durchführen muss.

Äh ja, also in etwa eines der Dinge, was man mit Transaktionen lösen möchte. Daten lesen → Daten verarbeiten → Daten aktualisieren ohne darüber nachdenken zu müssen, dass sie sich geändert haben könnten

mfg
Woodfighter

[Nooooooos]

Also, ist es denn nicht egal ob der Apache (oder welcher Server auch immer) threaded läuft? Es ist eher die Frage ob PHP threaded lauft, bzw. ob der PHP-Interpreter des Servers eine Seite nach der anderen abarbeitet oder ob er für zwei Seiten zwei Threads erstellt und diese vielleich auf zwei Prozessor(kernen) parallel verarbeitet.
Egal ob Locks oder Transaktionen - diese sind nur nötig wenn PHP die Seiten nicht seriell bearbeitet, der einzige Zugriff auf die Datenbank kommt von PHP her.

Wieso wollt ihr mir von Locks abraten und empfehlt stattdessen Transaktionen? Was ist der Vorteil von Transaktionen?

Ich habe noch nie mit Transaktionen gearbeitet, darum stellt sich mir die Frage, ob sich denn alle select-Aufrufe einer Transaktionen garantiert auf den exakt gleichen Datenstand beziehen. Anders gefragt: Kan man einen READ-Lock überhaupt auch mit Transaktionen realisieren? Sind Transaktionen mehr als einfach nur die Möglichkeit eine solche mit einem Rollback zu widerufen?
Ansonsten drängt sich ein Inkonsistenzproblem auf, denn die if-Abfrage, welche über einen Commit oder Rollback entscheidet, ist dann nicht atomisch.

Grüsse
Nooooooooooos

[dedlfix]

Hi!

Also, ist es denn nicht egal ob der Apache (oder welcher Server auch immer) threaded läuft? Es ist eher die Frage ob PHP threaded lauft, bzw. ob der PHP-Interpreter des Servers eine Seite nach der anderen abarbeitet oder ob er für zwei Seiten zwei Threads erstellt und diese vielleich auf zwei Prozessor(kernen) parallel verarbeitet.

Die Requests kommen beim Webserver rein. Nur der entscheidet, wann etwas an PHP weitergereicht wird. Und selbst wenn PHP als Modul in diesem läuft, ist es doch so geschrieben, dass Requests untereinander abgegrenzt laufen. Es ist auch nicht weiter interessant, auf welche Weise der Prozessor das Multitasking organisiert. PHP ist für Multitasking-Umgebungen designt, eine "Highländer"-Einstellmöglichkeit ist mir nicht bekannt. Bastel-Krücken mit File-Locks oder ähnlichem will ich lieber nicht erwähnen. Dein Problem beschränkt sich vom Prinzip her nicht auf PHP allein, auch wenn du nur damit auf das DBMS zuzugreifen planst. Konsequenterweise muss das DBMS-Handling transaktionsgesichert sein, wenn du dort keine inkonsitanten Daten haben willst, egal über welchen Weg man darauf zugreift.

Wieso wollt ihr mir von Locks abraten und empfehlt stattdessen Transaktionen? Was ist der Vorteil von Transaktionen? Ich habe noch nie mit Transaktionen gearbeitet, [...]

Hast du die bereits vorhandene Literatur im Allgemeinen und MySQL im Speziellen dazu angeschaut?

darum stellt sich mir die Frage, ob sich denn alle select-Aufrufe einer Transaktionen garantiert auf den exakt gleichen Datenstand beziehen.

Kommt (beim MySQL) auf das Isolation Level an (SET TRANSACTION ISOLATION LEVEL ...).

Lo!