Oft muss ein Webdienst mehrere große Dateien für den Download durch den Kunden komprimieren. Der naheliegendste Weg, dies zu tun, ist, eine temporäre Zip-Datei zu erstellen, und dann entweder echo an den Benutzer weiterzuleiten oder auf der Festplatte zu speichern und weiterzuleiten (und irgendwann in der Zukunft zu löschen).
Diese Vorgehensweise hat jedoch auch Nachteile:
- eine Anfangsphase mit intensivem CPU- und Festplatten-Thrashing, was zu...
- eine erhebliche anfängliche Verzögerung für den Benutzer, während das Archiv vorbereitet wird
- sehr hoher Speicherbedarf pro Anfrage
- Nutzung von erheblichem temporärem Speicherplatz
- bricht der Nutzer den Download auf halbem Weg ab, so sind alle in der Anfangsphase verbrauchten Ressourcen (CPU, Speicher, Festplatte) verschwendet worden
Lösungen wie ZipStream-PHP verbessern dies, indem sie die Daten Datei für Datei in den Apache schaufeln. Das Ergebnis ist jedoch immer noch eine hohe Speichernutzung (die Dateien werden vollständig in den Speicher geladen) und große, sprunghafte Spitzen bei der Festplatten- und CPU-Nutzung.
Betrachten Sie im Gegensatz dazu den folgenden Bash-Ausschnitt:
ls -1 | zip -@ - | cat > file.zip
# Note -@ is not supported on MacOSHier, zip arbeitet im Streaming-Modus, was zu einem geringen Speicherbedarf führt. Eine Pipe hat einen integrierten Puffer - wenn der Puffer voll ist, unterbricht das Betriebssystem das schreibende Programm (Programm auf der linken Seite der Pipe). Dadurch wird sichergestellt, dass zip arbeitet nur so schnell, wie seine Ausgabe von cat .
Der optimale Weg wäre also, dasselbe zu tun: Ersetzen cat mit einem Webserver-Prozess, Streaming die Zip-Datei an den Benutzer zu übermitteln, wobei die Datei im laufenden Betrieb erstellt wird. Dies würde im Vergleich zum Streaming der Dateien nur wenig Overhead verursachen und hätte ein unproblematisches, unauffälliges Ressourcenprofil.
Wie kann man dies mit einem LAMP-Stack erreichen?
