Hallo Linuchss,
beachte aber auch, dass PHP nicht den einzigen Watchdog-Timer an der Kette hat:
Ihr Webbserver kann andere Timeout-Einstellungen haben die ebenfalls die PHP-Ausführung unterbrechen können. Apache verfügt über eine TimeOut-Direktive und IIS hat eine CGI timeout Funktion. Beide sind als Standardwert auf 300 Sekunden eingestellt. Genauere Informationen finden Sie in der Dokumentation Ihres Webservers.
Dazu kommt noch ein Timeout im Browser.
Aber echte Langläufer lässt man auch nicht im Web laufen, sondern auf der Konsole. Die Doku schreibt dann:
Wird PHP von der Kommandozeile ausgeführt so ist der Vorgabewert 0.
Sprich: Es gibt dann kein Timeout. Eine Konsole hat man immer, und wenn der Webhoster einem keine erlaubt, dann eben mit einer PHP Installation auf dem eigenen Win/Lin/Mac-PC.
Wenn man es aus irgendwelchen ominösen Gründen unbedingt auf dem Webserver tun muss, und vom Browser aus antriggern, und es einfach nicht schneller geht, dann muss man versuchen, die Aufgabe sinnvoll zu teilen.
Zum Beispiel könnte man vor jedem fgets prüfen, wie lange das Script schon läuft. Kommt man in gefährliche Bereiche (deren Wert man im Zweifelsfall vom Browser per Query-Parameter mitgibt), merkt man sich mit ftell die aktuelle Position in der Eingabedatei, speichert die Arbeitsdaten in einer Datei (die hoffentlich nicht zu umfangreich sind) und meldet dem Browser zurück: teilweise fertig, ich war bei Position 47110815. Ein kleines JavaScript im Browser schickt dann den nächsten Request los, mit Parameter "mach bei Position 47110815 weiter" und das Script liest den Arbeitsstand wieder ein, positioniert die Eingabedatei mit fseek auf diese Position und verarbeitet den nächsten Block.
Eine Alternative wäre, die Eingabedatei zu teilen, sofern das fachlich möglich ist. Zum Beispiel mit einem Aufteilscript in 100000 Zeilenblöcke, und danach ruft man pro Block das Verarbeitungsscript auf.
Rolf
sumpsi - posui - obstruxi