Problem mit TimeOuts

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Problem mit TimeOuts

    Hallo,

    ich habe probleme mit einem Skript. Das Skript macht nichts verrücktes: Es sucht sich Daten aus einer MYSQL-Datenbank (ich sag mal, nicht wenige aber auch nicht Megabytes) schreibt sie sich in ein grohoßes Array und bereitet Sie html technisch zum download auf. Also, nichts ungewöhnliches prinzipiell. Allerdings sind es viele texte, es werden ca. 40 Texte mit meist mehr als 1000 Wörtern in der Datei verarbeitet.

    Dass der Vorgang länger dauert, ist also klar. Nach immer so ca. 34 Sekunden kriege ich einen "500 - Internal Server Error". Ich hab in der phpINfo nachgesehen, diese max_exec... flag steht auf 30 sekunden. Das nenne ich eine erdrückende Indizienlage. Das macht auch nichts, schneller wäre besser, aber ich glaube nicht dass ich performancetechnisch noch viel am skript ändern kann. mir wäre aber schon sehr daran gelegen, dass das skript einfach durchläuft und arbeitet, bis es fertig ist. ich habe diese set_timeout methode verwendet, ohne erfolg. wie kann ich überprüfen, ob diese methode diesen max_exec wert geändert hat bzw. ändern darf?

    über Fehler 500 kann man auch nichts spezifisches sagen, ist nach wiki eine sammelid für alles mögliche.

    nun habe ich von der server/konfigurations-seite nicht soo viel plan, was würdet ihr tun um das skript laufen zu lassen?

    grüße,

    einheitswurzel

  • Ich weiß nicht, wie meinst du das konkret?

    jedenfalls ist es sehr komisch. ich habe mal testweise ein skript gebaut und per for schleife einen sleep(1) ausgeführt. gleiches problem: lasse ich die for schleife bis 20 laufen, kein problem, passt. lasse ich die for schleife bis 40 laufen, fehler 500 nach etwa 34 sekunden. Es liegt also sehr sehr wahrscheinlich an einem timeout.

    habe mir mit ini_get den wert für die max_execution_time nach einem set_time_limit(0) geben lassen. Eine Veränderung des Flags findet also statt. Auch ein set_time_limit(60) greift. Ich habe nachgesehen, der safe_mode ist NICHT aktiviert. Denn läuft das Skript in einen fehler 500 nach 34 Sekunden.

    Welche timeout Mechanismen können mich denn da sonst noch ärgern?

    Grüße,

    einheitswurzel

  • Rufen denn echte Benutzer diese Seite auf, oder handelt es sich um ein Maintenance Script?

    Echte Benutzer sollten nie so lange auf ein Script warten müssen - da läuft irgendwas schief.
    Maintenance Script solltest du nicht im Webbrowser starten, sondern über Kommandozeile aufrufen.

    Ansonsten, um erstmal die Fehlerursache herauszufinden: Was steht denn in den Logfiles? Ein 500er Error wird normalerweise geloggt.
    Lg

  • Es ist keine Internetseite. Die generierte plist wird von einer anderen Anwedung als Datasource genutzt.

    die muss von außen erreichbar sein und darf ruhig etwas länger rödeln, wird sich bei der Datenmenge s.o. auch gar nicht vermeiden lassen, da bin ich mit 40 Sekunden noch ganz gut dabei, denk ich.

    das mit den logs hab ich nicht so drauf. hab auch irgendwie nur zugriff auf accesslog, die mir nicht mehr sagen, als ich eh schon weiß. Also log der form

    Quellcode

    1. 87.106.191.5 - - [12/Sep/2010:06:45:07 +0200] "GET /testcenter/iphone/morningpost/cronjobtest.php HTTP/1.0" 200 - "http://cronjob.de/?id=512322" "Cronjob.de"
    2. 212.227.101.211 - - [12/Sep/2010:06:46:27 +0200] "GET /testcenter/iphone/morningpost/ssnooper.php HTTP/1.0" 200 24376 "http://cronjob.de/?id=511908" "Cronjob.de"
    3. 87.106.191.5 - - [12/Sep/2010:06:50:05 +0200] "GET /testcenter/iphone/morningpost/cronjobtest.php HTTP/1.0" 200 - "http://cronjob.de/?id=512322" "Cronjob.de"
    4. 212.227.101.211 - - [12/Sep/2010:06:51:17 +0200] "GET /testcenter/iphone/morningpost/ssnooper.php HTTP/1.0" 200 24376 "http://cronjob.de/?id=511908" "Cronjob.de"
    5. 87.106.191.5 - - [12/Sep/2010:06:55:06 +0200] "GET /testcenter/iphone/morningpost/cronjobtest.php HTTP/1.0" 200 - "http://cronjob.de/?id=512322" "Cronjob.de"
    6. 212.227.101.211

  • wenn es keine Internetseite ist, dann solltest du die Aufrufe wirklich nicht über den Apache machen.
    Dazu ist er zum einen nicht gedacht. Zum anderen hast du beim Monitoring nicht mehr die Möglichkeit zu unterscheiden, welche Prozesse nun beim Benutzer verzögern - und welche nur Wartungstasks sind.
    Dein Cron Intervall ist auch ziemlich gering, dafür dass der Prozess mind. 40 Sekunden läuft.

    Lg

  • Ui, da haben wir einen Problemlöser was?
    Was gibt es denn für Möglichkeiten abseits des Webserver, das PHP-Skript laufen zu lassen und die resultierende an einen Client zu verfrachten? Das finde ich interessant.

    Aber davon abgesehen wäre es für mich auch erstmal ausreichend, meine ursprüngliche Frage beantwortet zu bekommen. Warum hackt das TimeOut dazwischen, ob wohl ich es auf 0 bzw. 1027 setze?

    Grüße,

    einheitswurzel

  • einheitswurzel schrieb:

    Aber davon abgesehen wäre es für mich auch erstmal ausreichend, meine ursprüngliche Frage beantwortet zu bekommen. Warum hackt das TimeOut dazwischen, ob wohl ich es auf 0 bzw. 1027 setze?


    Es könnte sein, das du den Wert nicht verändern kannst. Das ist meist vom Hoster gesperrt, da man mit sowas auch gut einen Server abschiessen kann.

    Wenn du set_time_limit(1027); nutzt, dann probier mal ini_set('max_execution_time', 1027);, vll. schafft das abhilfe.
    Ansonsten schau dir mal flush() an.


    Zum Thema, den Benutzer nicht warten zu lassen, ist es klar besser wenn man alles on the fly zu Verfügung hat, aber wenn man Livedaten benötigt, dann lässt sich das meistens nicht vermeiden.
    Man könnte höchstens eine Art Queue erstellen, wo der Benutzer die Daten anfordern kann und dann X Sekunden später sich die Daten vom Server downloaden kann, dann muss der Nutzer auf kein Script warten, wäre die schönere Variante, aber warten muss der Benutzer trotzdem ;)

  • einheitswurzel schrieb:

    Es ist keine Internetseite. Die generierte plist wird von einer anderen Anwedung als Datasource genutzt.

    Ich habe es eben erst realisiert - es wartet also kein wirklicher Benutzer. Konkret geht es um einen Cronjob Service der dein Maintenance Script ausführt.

    Es bleiben immer noch viele mögliche Ursachen:
    * welchen Timeout Wert benutzt denn der Client (also der Cronjob Service) - würde mich wundern, wenn er so lange Verbindungen offen hält
    * wie vince gesagt hat.. evtl kannst du den Wert gar nicht überschreiben
    * neben der PHP Konfig muss auch die Apache Konfig vorbereitet sein, siehe dazu php.net/manual/de/info.configu…hp#ini.max-execution-time

    Lösungsvorschläge:
    Wir können davon ausgehen, dass der Cronjob Service nicht auf eine Antwort wartet, oder? Das ist eine sehr wichtige Information! Alle Tipps haben sich darauf bezogen den Benutzer glücklich zu stellen.
    Das würde bedeuten, dass wenn du die entsprechenden Rechte hast, du einfach einen Hintergrundprozess starten kannst.

    Quellcode

    1. <?php
    2. exec('(php -f zweites_script.php) >/dev/null &');


    Das Script läuft dann wirklich so lange, bis es fertig ist - ohne Timeout Bestimmungen. Am besten du legst dir zusätzlich eine Lock Datei an, damit dein Script nicht mehrmals ausgeführt werden kann.