Das "done..." Problem, oder Hilfe bei Lighttpd und PHP

Also sind wir uns einig, dass es weniger geworden ist. Ich frage deshalb, da der Grund für das "done..." ist, dass der Webserver nicht schnell genug Antwort vom PHP kommt. Es kann also in zwei Richtungen gehen, einmal das PHP genug Anfragen verarbeiten darf und dann, dass PHP zuviele Anfragen gleichzeitig bekommt. Ich hatte auf letzteres getippt und ich schien wohl recht zu haben. Ich schraube ihn gleich noch einmal ordentlich runter.
 
Ich brauche keine Header mehr, wir wissen ja, woran es liegt. Nun müssen wir eine Konfiguration finden, die funktioniert, aber kein Flaschenhals wird.
 
Also ich hatte heute das erste mal das "done".

18:23 Uhr, Firefox 3.0b5, Ubuntu Linux

Firefox läuft mit diesem Quirks Mode laut Seiteninfo.

Gruß, Cessel
 
Hier auch zum ersten Mal das "...done " Problem aufgetreten.

Uhrzeit: 9:20 Uhr
Browser: Firefox 2.0.0.14 unter Windows XP
Seiteninfo zeigt Kompatiblitätsmodus (Quirks) an.
 
Ich bin aktuell bei
Code: 
"PHP_FCGI_CHILDREN" => "4",
"PHP_FCGI_MAX_REQUESTS" => "500"
was aber eigentlich viel zu wenig ist. Gerade bei Stoßzeiten. Es ist allerdings völlig egal, was ich dort Eintrage, das "Done..." verschwindet nicht. Ich sehe im Moment nur zwei Möglichkeiten:
- Das Problem mit Hardware totschlagen. Auf die Schnelle nicht möglich.
- Zurück zu Apache und damit leben, dass die Kiste sich kaputtswapt.
Alles andere scheint keine Option zu sein. Ich hab praktisch alles durch. Angefangen bei sicherlich 5 Versionen des mod_fcgi, über mehrere Wege das Ding zu starten, diverse Einstellmöglichkeiten. php-fcgi scheint im Moment einfach total kaputt zu sein. Mich ärgert dabei nur fürchterlich, dass ich den Mist nicht in der Testumgebung bemerkt habe :/
 
Ist dieses "Done" denn ein wirklich schwerwiegendes Problem? Ich bekomm es so selten (sprich in letzter Zeit garnicht), als das ich mit diesem Zustand leben kann.
 
Es geht's ums Prinzip. Wenn das Forum auf dem unter BSD-Systemen verbreitesten Browser nicht sauber läuft, ist das schon ein Problem, imo. Wobei ich auch dazu tendiere zu sagen "Nutzt nicht dies Gefrickel, was noch nie sauber lief, sondern einen richtigen Browser!" Allerdings wüsste ich auch, was dann passiert ;)
 
Da könnte ich noch einen draufsetzen und sagen, dass PHP ansich schon ein Problem "by design" ist - was aber auch niemanden wirklich weiterbringen würde :rolleyes:

IMHO liegen die Kinken wohl hauptsächlich in den FastCGI-Implementierungen. Bei mir (FBSD 7.0, lighty-1.4.19, php-5.2.6) konnte ich das "done" nicht provozieren, scheint also mehr an der Lastsituation als am verwendeten Browser zu hängen. Mit Apache und anderen über FastCGI angebundenen Sprachmodulen hab ich allerdings schon eine schöne 500er Serie hinbekommen (mit ab) - letztlich aus demselben Grund. So "fast" ist FastCGI dann halt doch wieder nicht...
 
Ist der Speicher in Ordnung?
Könntest du mal versuchen z.B. alle 30 min ein SIGTERM an alle fcgi-Prozesse zu versenden, damit die Sachen neu in den Speicher geladen werden?
Eine andere Möglichkeit wäre zu tracken, ob die fcgi-Prozesse irgendwann sterben und dann neu geladen werden, was anhand der pids kein Problem darstellen sollte. Wenn die Dinger sich von selbst zu den Ahnen gesellen hast du nen Anhaltspunkt, was da passiert...
 
Kann man wirklich ausschließen, dass es sich nicht um einen Bug in Gecko handelt?
Ich hab das Ding unter diversen Versionen des Konquerors noch nie gesehen!
 
Ich dachte es wäre inzwischen eindeutig festgestellt, dass es ein Bug in Gecko ist.

Yamagi will das Problem trotzdem zumindest mittelfristig serverseitig lösen, da Gecko ja doch die am weitesten verbreitetet Engine ist.
 
lupinix schrieb:
Meiner bescheidenen Ansicht nach ist es ein Bug in Gecko, sonst hat es ja kein Browser, wo kein Gecko drinne ist.
Zum Vergrößern anklicken....

Naja, Du warst derjenige der das Problem scheinbar einmal mit Konqueror hatte ;)
lupinix schrieb:
Also ich nehme in der letzten Zeit auch meist Firefox 3, da hatte ich das auch noch nicht, wenn ich das done hatte, dann mit Firefox2/Iceweasel2, Epiphany und einmal mit Konqueror.
Zum Vergrößern anklicken....
 
Nun, dann muss ich wohl noch mal was dazu sagen. Eigentlich ist es ganz simpel. Manchmal gibt lightty eine inkomplette Seite zurück. Alle Browser erkennen das, fordern neu an. Der Nutzer bemerkt bestenfalls eine längere Antwortzeit. An diesem Punkt trennen sich die Wege. Firefox rendert die unvollständige Version, Javascript explodiert und es gibt "done...", der Codebrowser zeigt aber die vollständige Version an. Andere Browser rendern die zweite Version. Dort tritt das Problem nur dann auf, wenn auch diese fehlerhaft ist, was wirklich unwahrscheinlich ist.
Natürlich spinnt Gecko hier. Aber ich will das problem trotzdem wirklich lösen. Aus zwei Gründen. Einen habe ich oben genannt, Gecko ist zu weit verbreitet. Der andere ist, ich löse gern Ursachen und keine Auswirkungen. Denn mache ich das, knallts eher früher als später wieder...
 
Jetzt ist ein neues Phänomen aufgetaucht: Eben wollte Firefox mir showthread.php zum Download anbieten. Beim zweiten Klick auf denselben Link wurde die Seite normal gerendert und dargestellt.
 
@Ogion: So stellt sich mir das "done..." Problem immer dar, wenn man die Datei herunterlädt, steht da "done..." drin.

Vielleicht ist es ja ein Teil einer Internet-Rally :D
 
Naa, bisher hat der Feuerfuchs das done immer angezeigt... scheint wohl davon abzuhängen, ob noch eine vernünftige Content-Type Angabe im Header gesendet wird oder ob die auch schon massakriert wurde :(
 
Meine neuerworbenen PSI-Kräfte (so eine Kristallkugel war mir zu teuer) sagen mir, dass sich das Problem gerade pulverisiert hat. Alles in allen kann man als Fazit sagen, dass Lighttpd ein schöner Webserver ist, leider ist PHP als Fast-CGI der letzte Schrott. Was man aber nur in unter extremen Lastsituationen bemerkt, verbunden mit ein paar anderen Faktoren. Es hat also nicht sein sollen. Und ich entschuldige mich hier noch einmal bei all unseren Nutzern für das nervende "done...".
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben