504 Gateway Time-out - Bei einem Update Script
bearbeitet von Google weiß alles> Was ich aber nicht ganz verstehe, warum hat der Server mit diesem Update weniger zu tun? Er muss doch ebenfalls alle Datensätze durchgehen, oder?
Stell Dir die Programme als Worker vor, also als menschliche Arbeiter, die einen Job erledigen sollen. Du hast davon 3: Webserver, PHP, Datenbankserver.
Bei Deinem Skript führen PHP und der Datenbankserver eine endlose Diskussion und PHP wartet jedes (in Deinem Fall wohl rund 28000) Mal höflich auf die Bestätigung vom Datenbankserver, verarbeitet diese und sendet dann den nächsten Befehl ... um wieder zu warten, die Antwort zu verarbeiten, den nächsten Befehl zu senden ... irgendwann hat der ebenfalls (auf PHP, vom Datenbankserver weiß er nichts) wartende Webserver die Schnauze voll, haut PHP mit der Schaufel tot und schickt dem Chef die Meldung: _"Eh! Der faule Hund PHP wird ewig nicht fertig. Hab ihn erwürgt und erledige jetzt den nächsten Job. Die Gewerkschaft sagt, ich darf das!"_ (Beim Apache wäre der Chef übrigens auch ein Apache, nämlich der "Vaterprozess" der die Worker steuert. Dessen "Chef" ist unter Unix/Linux dann der Herr "init".)
Hinzu kommt: Der Datenbankserver bekommt eine Anweisung und führt diese aus. Enthält EIN Befehl EINE Einfüge-oder Änderungsoperation so muss er danach "aufräumen" (z.B. Indexe erneuern, den Ausgabekanal öffnen und melden was er getan hat und ob das klappte: Hier etwas wie "1 Zeile betroffen"). Er macht das also auch **28000** mal. Führt er auf Grund EINES anderen Befehles die 28000 Operationen aus, dann "räumt er **einmal** auf" und meldet EIN mal etwas wie: "28000 Zeilen betroffen"
Es ist ziemlich offensichtlich, dass das schneller geht - oder?
504 Gateway Time-out - Bei einem Update Script
bearbeitet von Google weiß alles> Was ich aber nicht ganz verstehe, warum hat der Server mit diesem Update weniger zu tun? Er muss doch ebenfalls alle Datensätze durchgehen, oder?
Stell Dir die Programme als Worker vor, also als menschliche Arbeiter, die einen Job erledigen sollen. Du hast davon 3: Webserver, PHP, Datenbankserver.
Bei Deinem Skript führen PHP und der Datenbankserver eine endlose Diskussion und PHP wartet jedes (in Deinem Fall wohl rund 28000) Mal höflich auf die Bestätigung vom Datenbankserver, verarbeitet diese und sendet dann den nächsten Befehl ... um wieder zu warten, die Antwort zu verarbeiten, den nächsten Befehl zu senden ... irgendwann hat der ebenfalls (auf PHP, vom Datenbankserver weiß er nichts) wartende Webserver die Schnauze voll, haut PHP mit der Schaufel tot und schickt dem Chef die Meldung: _"Eh! Der faule Hund PHP wird ewig nicht fertig. Hab ihn erwürgt und erledige jetzt den nächsten Job. Die Gewerkschaft sagt, ich darf das!"_ (Beim Apache wäre der Chef übrigens auch ein Apache, nämlich der "Vaterprozess" der die Worker steuert. Dessen "Chef" ist unter Unix/Linux dann der Herr "init".
Hinzu kommt: Der Datenbankserver bekommt eine Anweisung und führt diese aus. Enthält EIN Befehl EINE Einfüge-oder Änderungsoperation so muss er danach "aufräumen" (z.B. Indexe erneuern, den Ausgabekanal öffnen und melden was er getan hat und ob das klappte: Hier etwas wie "1 Zeile betroffen"). Er macht das also auch **28000** mal. Führt er auf Grund EINES anderen Befehles die 28000 Operationen aus, dann "räumt er **einmal** auf" und meldet EIN mal etwas wie: "28000 Zeilen betroffen"
Es ist ziemlich offensichtlich, dass das schneller geht - oder?
504 Gateway Time-out - Bei einem Update Script
bearbeitet von Google weiß alles> Was ich aber nicht ganz verstehe, warum hat der Server mit diesem Update weniger zu tun? Er muss doch ebenfalls alle Datensätze durchgehen, oder?
Stell Dir die Programme als Worker vor, also als menschliche Arbeiter, die einen Job erledigen sollen. Du hast davon 3: Webserver, PHP, Datenbankserver.
Bei Deinem Skript führen PHP und der Datenbankserver eine endlose Diskussion und PHP wartet jedes (in Deinem Fall wohl rund 28000) Mal höflich auf die Bestätigung vom Datenbankserver, verarbeitet diese und sendet dann den nächsten Befehl ... um wieder zu warten, die Antwort zu verarbeiten, den nächsten Befehl zu senden ... irgendwann hat der ebenfalls (auf PHP, vom Datenbankserver weiß er nichts) wartende Webserver die Schnauze voll, haut PHP mit der Schaufel tot und schickt dem Chef die Meldung: _"Eh! Der faule Hund PHP wird ewig nicht fertig. Hab ihn erwürgt und erledige jetzt den nächsten Job. Die Gewerkschaft sagt, ich darf das!"_
Hinzu kommt: Der Datenbankserver bekommt eine Anweisung und führt diese aus. Enthält EIN Befehl EINE Einfüge-oder Änderungsoperation so muss er danach "aufräumen" (z.B. Indexe erneuern, den Ausgabekanal öffnen und melden was er getan hat und ob das klappte: Hier etwas wie "1 Zeile betroffen"). Er macht das also auch **28000** mal. Führt er auf Grund EINES anderen Befehles die 28000 Operationen aus, dann "räumt er **einmal** auf" und meldet EIN mal etwas wie: "28000 Zeilen betroffen"
Es ist ziemlich offensichtlich, dass das schneller geht - oder?
504 Gateway Time-out - Bei einem Update Script
bearbeitet von Google weiß alles> Was ich aber nicht ganz verstehe, warum hat der Server mit diesem Update weniger zu tun? Er muss doch ebenfalls alle Datensätze durchgehen, oder?
Stell Dir die Programme als Worker vor, also als menschliche Arbeiter, die einen Job erledigen sollen. Du hast davon 3: Webserver, PHP, Datenbankserver.
Bei Deinem Skript führen PHP und der Datenbankserver eine endlose Diskussion und PHP wartet jedes (in Deinem Fall wohl rund 28000) Mal höflich auf die Bestätigung vom Datenbankserver, verarbeitet diese und sendet dann den nächsten Befehl ... um wieder zu warten, die Antwort zu verarbeiten, den nächsten Befehl zu senden ... irgendwann hat der ebenfalls (auf PHP, vom Datenbankserver weiß er nichts) wartende Webserver die Schnauze voll, haut PHP mit der Schaufel tot und schickt dem Chef die Meldung: _"Eh! Der faule Hund PHP wird ewig nicht fertig. Hab ihn erwürgt und bin jetzt heimgegangen. Die Gewerkschaft sagt, ich darf das!"_
Hinzu kommt: Der Datenbankserver bekommt eine Anweisung und führt diese aus. Enthält EIN Befehl EINE Einfüge-oder Änderungsoperation so muss er danach "aufräumen" (z.B. Indexe erneuern, den Ausgabekanal öffnen und melden was er getan hat und ob das klappte: Hier etwas wie "1 Zeile betroffen"). Er macht das also auch **28000** mal. Führt er auf Grund EINES anderen Befehles die 28000 Operationen aus, dann "räumt er **einmal** auf" und meldet EIN mal etwas wie: "28000 Zeilen betroffen"
Es ist ziemlich offensichtlich, dass das schneller geht - oder?
504 Gateway Time-out - Bei einem Update Script
bearbeitet von Google weiß alles> Was ich aber nicht ganz verstehe, warum hat der Server mit diesem Update weniger zu tun? Er muss doch ebenfalls alle Datensätze durchgehen, oder?
Stell Dir die Programme als Worker vor, also als menschliche Arbeiter, die einen Job erledigen sollen. Du hast davon 3: Webserver, PHP, Datenbankserver.
Bei Deinem Skript führen PHP und der Datenbankserver eine endlose Diskussion und PHP wartet jedes (in Deinem Fall wohl rund 28000) Mal höflich auf die Bestätigung vom Datenbankserver, verarbeitet diese und sendet dann den nächsten Befehl ... um wieder zu warten, die Antwort zu verarbeiten, den nächsten Befehl zu senden ... irgendwann hat der ebenfalls (auf PHP, vom Datenbankserver weiß er nichts) wartende Webserver die Schnauze voll, haut PHP mit der Schaufel tot und schickt dem Chef die Meldung: _"Eh! Der faule Hund PHP wird ewig nicht fertig. Hab ihn erwürgt und bin jetzt heimgegangen. Die Gewerkschaft sagt, ich darf das!"_
Hinzu kommt: Der Datenbankserver bekommt eine Anweisung und führt diese aus. Enthält EIN Befehl EINE Einfüge-oder Änderungsoperation so muss er danach "aufräumen" (z.B. Indexe erneuern, den Ausgabekanal öffnen und melden was er getan hat und ob das klappte: Hier etwas wie "1 Zeile betroffen"). Er macht das also auch **28000** mal. Führt er auf Grund EINES anderen Befehles die 28000 Operationen aus, dann "räumt er **einmal** auf" und meldet EIN mal etwas wie: "28000 Zeilen betroffen"