Hi,
Streaming heißt für mich, dass die übermittelten Daten direkt verarbeitet werden (...) (Ansicht deckt sich nur), wenn das Speichern als Datei der eigentliche Zweck der Operation ist.
Ja, so hatte ich das aufgefasst. Upload auf einen Server zum Zweck der Multimedia-Wiedergabe ist wohl eher ein Sonderfall. Und ich habe Streaming nicht auf Audio/Video beschränkt gesehen, es ging mir um den Umgang mit dem Datenstrom. Ich denke, unsere Ansichten decken sich.
In PHP ist das bei multipart/form-data so gelöst, dass anhängende Uploads vom Server automatisch als Temp-Dateien gespeichert und nicht im RAM gehalten werden. Allerdings deute ich die Hinweise auf die RAM-Limitierung in der PHP-Doku so, dass auch PHP eine einzelne Datei erstmal im RAM montiert bevor sie in den TEMP-Ordner kommt.
Woraus liest du das ab? AFAIK gibt es für PHP generell ein einstellbares Speicherlimit, das die verfügbare RAM-Menge pro Script begrenzt. Das hat aber mit File-Uploads nichts zu tun. Und dann gibt es ein Größenlimit für Uploads, das aber IMO nicht darauf schließen lässt, dass die Daten zunächst im RAM gehalten werden.
Einmal diese grundsätzlichen Infos zum Upload per POST. Das $_FILES Array enthält einen Temp-Namen, also gibt's auch eine Temp-Datei :)
Dass PHP die Datei im Speicher montiert bevor es sie schreibt schließe ich hieraus. Da steht, dass das Limit der Dateigröße 2 MB beträgt und man bei Erhöhen der upload_max_filesize eventuell das memory_limit anpassen muss.
Aus Sicht der RAM-Nutzung des Servers ist ein multipart-Upload von 10 Dateien zu je 100 MB also besser als eine Codierung dieser 10 Dateien in einen 1GB Klotz.
Hmm. Ich würd' mal sagen, das macht keinen Unterschied.
Wenn's einer macht, nicht. Unter diesem Gesichtspunkt betrachten viele Entwickler ihr Web. Aber das Schlimmste, was dann passieren kann, ist der Erfolg der Webseite. Auf einmal kracht es, weil die Requests zu viele Ressourcen verbraten. Wenn aber 500 Leute eine 100MB Datei hochladen (z.B. zu einem Fotobuch-Hersteller, kurz vor Weihnachten), werden auf einmal 50GB RAM nur zum Puffern gebraucht. Es geht also letztlich darum, wieviele Webserver man in den Cluster stellen muss, um X User bedienen zu können. Wenn jeder Request nur 100KB Streaming-Buffer hält, reicht für den Beispielfall ein Server (naja ok, bei soviel Last habe ich eh einen zweiten als Backup). Wenn aber alles in den RAM muss, brauche ich schnell 4 oder 8 Kisten.
Bei unbekannten Content-Typen sagt das PHP Handbuch, dass es auf die SAPI-Implementierung ankäme, ob die POST Daten gepuffert würden oder nicht.
Schade, dass du die Stelle nicht verlinkt hast. Ich vermute nämlich, du hast das missverstanden.
Hier, die Note zu php://input.
Ungepuffert würde bedeuten: sie bleiben als IP Pakete auf der Leitung (und der Client wartet), bis das PHP losläuft und sie liest.
Nein, das läuft so nicht. AFAIK nimmt der Webserver den vollständigen POST-Request entgegen, bevor er den PHP-Prozess überhaupt startet.
Ok, jetzt drehen wir den Bratspieß mal um. Kannst Du dafür eine Quelle angeben? :)
Rolf