Kommentare zu: Dateidownload via PHP mit Speedlimit und Resume

Von: Ronny

Ronny — Tue, 01 Feb 2011 08:03:31 +0000

Hi,

hab das Script ein wenig verändert um andere Mimetypes zu unterstützen und habe momentan das Problem, das .mp4 Videos in Chrome 8.0.552.237 nicht funktionieren, in Chrome 10 (Canary Build) jedoch dann wieder laufen. Ist das ein Bug in Chrome, jemand ne Ahnung. Ansonsten läuft das Script ganz wunderbar, danke dafür! Noch eine andere Frage, in wieweit geht es auf die Performance, gibts da Erfahrungen?

Grüße

Von: Linkliste 7 at Random People

Linkliste 7 at Random People — Sun, 16 Jan 2011 05:07:01 +0000

[...] High School – Engadget German Windows-Netzwerkeinstellungen einfach umschalten | heise Netze Dateidownload via PHP mit Speedlimit und Resume | PHP Gangsta – Der PHP Blog Schutz vor nervigen Spamanrufen Windows XP Pro: Mehr Zugriffe f?r Remote-PCs – PC-WELT [...]

Von: Robert

Robert — Wed, 10 Nov 2010 09:52:36 +0000

Hi, ich hatte jüngst mit deinem Code ein Problem: HTTPS-Dateidownload mit IE6/7/8. Und zwar fehlte der folgende Header:

header('Pragma: public');

Sobald dieser gesetzt ist, können auch IEs die Datei per HTTPS herunterladen.

Diese Bugs sind Microsoft bekannt:
http://support.microsoft.com/kb/812935/en-us
http://support.microsoft.com/kb/323308/en-us

VG
Robert

Von: deluxe.cd

deluxe.cd — Wed, 22 Sep 2010 10:11:38 +0000

Nice Script – Thanks for sharing! Allerdings solltest du noch eine kleine if ($wait < 1000000) vor dem usleep ergänzen, für den Fall, dass der flush länger als 1 Sekunde benötigt…

Von: Serverumzug fast fertig | davidsCorner.de

Serverumzug fast fertig | davidsCorner.de — Mon, 02 Aug 2010 14:48:05 +0000

[...] einen wäre da der Artikel “Dateidownload via PHP mit Speedlimit und Resume” auf phpgangsta.de oder die GIT 101 Präsentation von Scott Chacon. Außerdem war ich auf der Suche [...]

Von: Linkhub – Woche 09-2010 « pehbehbeh

Linkhub – Woche 09-2010 « pehbehbeh — Sun, 07 Mar 2010 16:48:12 +0000

[...] Dateidownload via PHP mit Speedlimit und Resume [...]

Von: Malte

Malte — Fri, 05 Mar 2010 22:12:31 +0000

nice! list($seekStart, $seekEnd) = array_map('intval', explode('-', substr($_SERVER['HTTP_RANGE'], 6), 2));

Von: Sascha Presnac

Sascha Presnac — Fri, 05 Mar 2010 11:52:38 +0000

@Ralph: Okay, hätten wir den begriff definiert und mit dieser Definition gehe ich mit dir konform. Manche verwechseln allerdings Hype und SOTA und von daher bin ich eher vorsichtig, wenn es um diese Begriffe geht.
Man hat halt immer den alten Konflikt, die Entscheidung zwischen “Never touch a running system” (was läuft, ist gut) und dem “look over your horizon”-prinzip (neues lernen, besser werden) und muss auch jedesmal schauen, was sich für die Situation besser eignet.

Von: Ralph Meier

Ralph Meier — Fri, 05 Mar 2010 10:56:09 +0000

@Sascha: Grundsätzlich stimme ich mit Dir überein, dass man nicht immer jedem Hype nachrennen sollte. Trotzdem muss man neue Wege gehen, wenn man sich weiterentwickeln will. Das heisst man muss auch neue Dinge ausprobieren. State of the art sind für mich Dinge, die sich schon eine Weile bewähren (also nicht zu verwechseln mit einem Hype).

Von: Sascha Presnac

Sascha Presnac — Fri, 05 Mar 2010 10:50:15 +0000

@Ralph: IMHO sollte man das ganze SOTA Gerede nicht überbewerten. Die beste Variante ist die, mit der ihr a) euch gut auskennt und die b) am besten zur Aufgabe passt.

Von: Ralph Meier

Ralph Meier — Fri, 05 Mar 2010 10:10:38 +0000

Es ist ja so… eine Weile lang hat “man” ja gehört, dass es cool ist Bilder in der DB als Blob zu speichern. So hat es dann auch unser Chef uns nahegelegt.

Ahnungslos gingen wir an die Geschichte heran und hatten seither nur Probleme damit.

2 Hauptprobleme, welche sich für mich herausgestellt haben:
- Bei einer 8MB Datei (z.B. PDF) braucht der MySQL Server ca. 100MB RAM
- Wir hatten permanent Probleme mit der Ausgabe als Blob-Stream (ja, wieder einmal der IE6 + IE7). Es mussten verschiedene Varianten ausprogrammiert werden -> HTTP Header

Am Anfang war ich auch noch der Meinung, dass es eine gute Idee ist, Files in der DB zu speichern (Es sind ja auch Daten). Das Backup ist bereits erledigt und es ist alles schön an einem Ort.
Inzwischen würde ich aber wieder die File Variante bevorzugen.

Es wäre aber noch interessant, wenn jemand sagen könnte, was aktuell State of the art ist und warum?

Von: Michael Kliewe

Michael Kliewe — Fri, 05 Mar 2010 09:59:30 +0000

Ist natürlich auch abhängig von den Rahmenbedingungen, aber eine Datenbank sollte wenn möglich klein gehalten werden damit sie in den RAM des Servers passt. Wenn ich nun viele Gigabytes an Daten in die Datenbank lege (als BLOBs natürlich) wird die Datenbank zwangsweise langsamer. Man stelle sich vor, Flickr legt alle Bilder in einer Petabyte-großen Datenbank ab. Oha!
Backups und Replikation dauern dann auch dementsprechend länger. Man müßte, je nach Einsatzzweck, nicht nur den Dateiinhalt selbst speichern, sondern auch den Dateinamen + Erstellungszeit + Last-Modified-Zeitpunkt. Alles Dinge, die das Dateisystem von Haus aus beherrscht.
Falls man inkrementelle Backups der Dateien machen möchte (tägliches Backup, nur die geänderten Dateien werden auf Band gespeichert oder so) ist das mit Dateien in der Datenbank komplizierter als einfach z.B. ein rsync des Dateisystems.
Des weiteren belastet man den häufig eh bereits ausgelasteten Datenbankserver unnötig. Wie wir wissen ist ja die Datenbank oft das Nadelöhr eines größeren Projekts. Wenn man Dateien auf der Festplatte speichert, kann man diese sehr einfach via Lighty/Nginx etc. an den Browser ausliefern, man muss weder den Apache noch die Datenbank damit belasten. Habe mal den Faktor 10 gelesen bei der Auslieferung von Dateien aus einer Datenbank.
Außerdem muss man im Fall einer Datenbank Dinge wie Resume, partieller Download oder “If-Modified-Since”-Header selbst nachbauen.
Soweit ich weiß kann man aus BLOBs nicht nur Teile auslesen (also beispielsweise die ersten 100KB oder so), man muss immer das ganze Feld abfragen. Damit wird Resume bzw. partieller Download quasi unmöglich.
BLOBs in einer Datenbank sind größenbeschränkt (4GB in MySQL, 2GB in Postgresql). Wird man zwar selten erreichen, aber ist eine Grenze die ein modernes Dateisystem nicht hat.
Falls man sein Projekt bei einem Hoster liegen hat gibt es mitunter auch Größenbeschränkungen der Datenbank auf 100MB oder so.

Ich überlege gerade auch was passiert mit PHP, wenn ich eine 500MB “Datei” aus der Datenbank lade und an den Browser ausliefere. Frisst mein PHP-Prozess dann eventuell 500MB RAM, weil ich die Daten ja in einer Variablen halten muss?

Arg, ist doch nicht so “kurz” geworden wie du wolltest. Das sind so die Dinge die mir auf Anhieb durch den Kopf schiessen, mag noch viele andere Vor- und Nachteile geben, wäre natürlich gut wenn du/ihr noch welche nennt.

Von: Ralph Meier

Ralph Meier — Fri, 05 Mar 2010 09:18:21 +0000

Kannst Du kurz erklären, warum du upload von Files in DB’s als böse erachtest? Wir hatten schon einige Diskussionen warum ja und warum nein.

Von: Sascha Presnac

Sascha Presnac — Thu, 04 Mar 2010 14:06:06 +0000

@Michael Kliewe: Das Firefox-AddOn heißt DownThemAll und ist hier zu finden: https://addons.mozilla.org/de/firefox/addon/201

Von: Michael Kliewe

Michael Kliewe — Thu, 04 Mar 2010 12:11:49 +0000

Für Abwärtskompatibilität gebe ich dir recht, da könnte man auch mime_content_type nehmen. ABER: Wenn man hier guckt
http://php.net/manual/en/function.mime-content-type.php
liest man dass die Funktion bereits Deprecated ist und nicht mehr genutzt werden soll, deshalb hab ich FileInfo genutzt. Aber für alte Systeme wo man kein FileInfo installieren kann ist es eine gute Lösung.
Eine andere mögliche Lösung sind Funktionen, die anhand der Dateiendung einen Mimetype bestimmen. Ist aber auch nur eine Zwischenlösung, da Endungen umbenannt werden können, die ersten Bytes einer Datei aber zuverlässig den Mimetype verraten.

An die Tools kann ich mich nicht genau erinnern, gibt ja so viele davon, die bekanntesten sind wohl
http://www.freedownloadmanager.org/
http://www.flashget.com/index_en.htm
Ich hatte aber glaub ich auch schonmal ein Firefox-Addon was Resume und paralleles Downloaden einer Datei konnte.

Von: Kevin

Kevin — Thu, 04 Mar 2010 11:53:01 +0000

Wenn ich das recht sehe, nutzt Du fileinfo hier nur für den Mimetype?
Das geht, zwecks Abwärtskompatibilität, auch ohne:
echo mime_content_type($filename);

Das flush() ist innerhalb der Schleife zwar logisch korrekt, kann aber bei ungünstigen Parametern krassen Overhead erzeugen.
Wenn man zig parallele Downloads künstlich lange in der Queue hält, sollte man sich auch seine Webserver Konfiguration nochmal gut anschauen, nicht das irgendwann die Connections auslaufen… aber die Diskussion hat ja nicht direkt mit Deinem Script zu tun

Wirklich eine sehr, sehr schöne Lösung! Danke das Du das mit uns teilst, ich hab auch schon gleich eine Idee wo ich das verwenden kann.

Könntest Du vielleicht kurz schreiben, mit welchen Tools Du das Resume bzw. die parallelen Downloads getestet hast? Bin neugierig ob die Tools sich da alle gleich verhalten.

Von: chrisse

chrisse — Thu, 04 Mar 2010 10:36:50 +0000

tolles skript, wie man den D/L speed throttlen kann hat mich schon immer interessiert.

Von: Speedlimit und Resume bei Downloads mit PHP - Standard, Zukunft, Snippet-Kiste, FileInfo, Extension, Artikel, Gangsta, Guter - homepagebewertung.de

Thu, 04 Mar 2010 09:22:04 +0000

[...] Artikel von PHP Gangsta, setzt zwar die Extension FileInfo voraus, diese ist aber seit PHP 5.3 Standard, für die Zukunft [...]

Von: Sascha Presnac

Sascha Presnac — Thu, 04 Mar 2010 09:14:50 +0000

Das ist eine super Sache. Nicht, dass ich dannach gesucht hätte, aber nun kenne ich zumindest sowas und evtl. braucht man es ja mal.
Danke für dieses tolle Beispiel!