Daten über Pipe am Childprozess in Empfang nehmen

[der_Kay]

Überleg Dir mal:

- Wenn es um "große" Dateien geht entfällt vielleicht der zehnt-MILLIONSTE Teil auf die Verarbeitung des Request-Headers. Ob das per FastCGI/PHP oder C++ passiert, ist sowas von dermaßen unerheblich...

- Wann genau der Eintrag von mod_accesslog rausgeht, wechselwirkt mit zig Faktoren. Man weiß nicht mal, ob das wirklich nach der Übertragung passiert. Die einzige Möglichkeit, das zu messen, wäre die Zeit vor und nach print file_get_contents() zu stoppen.

- Was verstehst Du in dem Zusammenhang unter Performance? Wenn lighttpd oder Apache eine Riesendatei versenden, unterscheiden sie sich doch überhaupt nicht voneinander.

Nimm PHP, schalt die maximale Scriptdauer ab und mach Dir nicht so einen Riesenstress....

 

[pingu12]

- Wenn es um "große" Dateien geht entfällt vielleicht der zehnt-MILLIONSTE Teil auf die Verarbeitung des Request-Headers. Ob das per FastCGI/PHP oder C++ passiert, ist sowas von dermaßen unerheblich...

Es geht mir natürlich nicht um die Verarbeitungszeit, sondern um die Vermutung, dass ich erheblich Ressourcen spare indem ich das Ausspucken der Dateien dem httpd überlasse welcher dafür geschrieben wurde. Lasse ich das jetzt php machen, dann muss die jeweilige Funktion (z.B. passthru) die ganze Datei erstmal einlesen und an den Webserver übergeben. Dort sehe ich den ersten Nachteil.
Punkt zwei ist, dass bei 100 gleichzeitigen Downloads dann 100 php-scripts offen sind die Speicher verbrauchen und CPU-Overhead erzeugen werden.
In beiden Punkten fehlt mir jede Menge fundiertes Hintergrundwissen um sicher zu sein aber egal mit wem ich je gesprochen habe hieß es immer möglichst NICHT php zur Auslieferung nutzen.
Gern (sehr gern) lasse ich mich eines besseren beleeren von jemandem der jenes Wissen hat.

- Wann genau der Eintrag von mod_accesslog rausgeht, wechselwirkt mit zig Faktoren. Man weiß nicht mal, ob das wirklich nach der Übertragung passiert. Die einzige Möglichkeit, das zu messen, wäre die Zeit vor und nach print file_get_contents() zu stoppen.

Da kommt es in meinem Falll auf Milisekunden nicht an. Ich habe per Test gesehen, dass der Eintrag mit dem Fertigwerden eines Downloads einhergeht.

- Was verstehst Du in dem Zusammenhang unter Performance? Wenn lighttpd oder Apache eine Riesendatei versenden, unterscheiden sie sich doch überhaupt nicht voneinander.

Ich denke doch. Und zwar in dem Moment wo es darum geht 100 riesen Dateien zu versenden. Das ist doch genau die Daseinsberechtigung für Lighttpd wenn mich nicht alles täuscht?

 

[der_Kay]

Ok. Nun versteh ich das Anforderungsprofil etwas besser. In pragmatischer Hinsicht funktioniert das ja auch und wenn wirklich keinerlei sonstiger Content ausgeliefert wird, würde ich das vielleicht sogar auch so machen.

Nur: Die Leseoperation Deines Tools wechselwirkt mit der Funktion von lighttpd und wehe, wenn es abstürzt, egal wie es gestartet wurde. Wenn wahnsinnig viele Requests eingehen würde ich vielleicht aus Stabilitätsgründen ein absolut triviales, minimales (Perl-)Script schreiben, das alles, was aus mod_accesslogg rauskommt in eine DATEI mit fortlaufendem Namen schreibt, die geschriebenen Bytes/Zeilen zählt und periodisch einfach eine neue Datei anlegt. Das Output wird dann batchweise geparst und in eine Datenbank geschrieben, einfach um zu verhindern, dass lighttpd gestört wird.

Und zu den Stärken von lighttpd: Der Performance-Vorteil liegt darin, REQUEST-Stürme schneller abarbeiten zu können, wenn z. B. index.html-s mit zig runden Tabellenrahmenecken, Thumbnails, iframes etc. angefordert wird. Da liefert es die Seite schneller aus, weil die Requests schneller geparst, die Domains schneller ausgelöst werden und der Content schneller gefunden wird. Sprich: Das Aufkommen von Requests und die Größe des angeforderten Contents klaffen nicht wesentlich auseinander.

Das eigentliche Ausliefern einer "Riesen"-Datei ist die döfstmögliche Operation, die ein Webbrowser machen kann. Das ist eine einzige while()-Schleife, die einen Filedeskriptor ausliest, die Bytes in einen Socket schreibt und deshalb 99% der Laufzeit mit Warten auf das Ende einer blockierenden I/O-Operation verbringt. Da ist es total egal, ob die Schleife in C++, Java oder PHP läuft, denn letztendlich sind das alles Systenmrufe, die da bremsen.

 

[pingu12]

Das eigentliche Ausliefern einer "Riesen"-Datei ist die döfstmögliche Operation, die ein Webbrowser machen kann. Das ist eine einzige while()-Schleife, die einen Filedeskriptor ausliest, die Bytes in einen Socket schreibt und deshalb 99% der Laufzeit mit Warten auf das Ende einer blockierenden I/O-Operation verbringt. Da ist es total egal, ob die Schleife in C++, Java oder PHP läuft, denn letztendlich sind das alles Systenmrufe, die da bremsen.

Doch wieder zurück zu passthru() und die DB-Geschichten dahinter? Wieso höre ich immer "Downloads nicht mit PHP!"?

Wenn wahnsinnig viele Requests eingehen würde ich vielleicht aus Stabilitätsgründen ein absolut triviales, minimales (Perl-)Script schreiben, das alles, was aus mod_accesslogg rauskommt in eine DATEI mit fortlaufendem Namen schreibt, die geschriebenen Bytes/Zeilen zählt und periodisch einfach eine neue Datei anlegt. Das Output wird dann batchweise geparst und in eine Datenbank geschrieben, einfach um zu verhindern, dass lighttpd gestört wird.

Ok, ich lerne mir also fix bissle Perl an und lasse lighttpd die Logdaten direkt übergeben an mein Perl-Script. Jenes legt alle drei Sekunden eine Datei mit ungeparsten logdaten an und startet gleich noch ein Bashscript auf die neue Datei welches parst und meine Datenbankoperationen aus dem bashscript heraus ausführt?