[php] Berechnung der Groesse einer ZIP-Datei

[Eddi]

Timo Schmidt schrieb:

> Voraussetzung dafür ist natürlich (wie im Ausgangsposting geschrieben),
> dass die ZIP-Datei ohne Kompression (-0) geschrieben wird.

Das ist schon klar geworden, nur wollte ich mit meinem Einwand des
-Response-Headers und "SHOULD"- vielleicht auf etwas völlig anderes
hinaus. Aber dann halte ich mich ersteinmal an Deine Antwort:

Du verschenkst Bandbreite und dort sehe ich eher einen Flaschenhals als
beim verbrachten Speicher. Oder hast Du einen hohen Datendurchsatz des
Netzwerkes im Vergleich zum Speicher der zugrundeliegenden Maschine?

>>Das Punkt (a) Relevanz hat, sehe ich auch nicht; zumal ich davon
>>ausgehe, daß die zip-Files später mit Kompressionsfaktor 9 serviert
>>werden sollen und hier die Rechenzeit auf die Ausführung des Programmes
>>zip verwendet wird.
> 
> Siehe oben. Die Kompression wird mittels Schalter "-0" ausgeschalten. Mir
> geht es auch nicht um Kompression sondern darum, mehrere Dateien mit
> einem Downloadvorgang auf den Client zu schieben.

Dies war zu vermuten. Die Daten, die in den Ausgabepuffer geschrieben
werden, können seites des Script-Steuerflußes nicht mehr angefaßt
werden. Darin liegt ja gerade der Vorteil von passthru().
 Der einzige Grund für die fehlende Kompression ist die einfache
Handhabung beim Berechnen der Dateigröße bei schlichter Inkaufnahme,
unnötig (da unkomprimiert) Daten durch die Leitung zu jagen.

Ich sehe nach wie vor zwei Möglichkeiten:

Einen nicht ganz standardkonformen Responseheader zu senden und auf die
Angabe von "Content-Lenght" verzeichten.

Einen standardkonformen Responseheader zu senden und das dazu
notwendigen Zwischenspeichern hinzunehmen.

In meiner ersten Antwort habe ich begründungslos den naheliegensten
(korrekten) Weg beschrieben. Nach wie vor sehe ich keinen anderen Weg.

>>Punkt (b) hängt wesentlich auch von der erwarteten Größe der
>>entstehenden zip-Files ab und kann in der Tat ein Problem sein, wenn
>>die Gefahr des Resourcenverbrauchst real gegeben ist.
> 
> Die Größe der einzelnen Dateien schwankt zwischen 0.5 - 30 MB, kann in
> Einzelfällen auch mal über die 50 MB Grenzen steigen. Die Anzahl der
> Dateien liegt zwischen einer und über 25 Dateien. Es kann also durchaus
> vorkommen, dass in der Summe eine Datenmenge von über 100 MB zustande
> kommt. Die in einer Variablen zu halten ist schlicht albern.

Im Hinblick auf die einzig andere Möglichkeit die Daten auf die
Festplatte zu speichern vielleicht...
 Wie hoch ist die durchschnittlich zu erwartende Kompression in Pozent?
 Wieviel Speicher seht zu welcher Bandbreite zur Verfügung?
 Reden wir über ein Intranet oder schlicht und einfach über einen
Webserver im Internet?

> Die Daten
> temporär ins Dateisystem zu schreiben bringt Umstände mit sich, die ich
> vermeiden möchte: Zeitaufwand, Aufräumen der temporär geschriebenen
> Dateien, Vermeidung des Überlaufs der Partition, in die die temporären
> Dateien geschrieben werden, ...

Der Zeitaufwand in dem Sinne, daß erst alles auf die Platte gesetzt
werden Muß, bevor serviert werden kann, brachte auch Christoph ins
Spiel. In diesem Fall ist er auch berechtigt, den bei 30 MB mit 25
einzelnen Datein und Kompression 9 reden wir von vielleicht 4 Sekunden...
 Wenn es also kein Intranet ist, wird die zu erwartende Ersparnis an
Downloadzeit (und damit verbunden Bandbreite) erhelblich gößer sein, als
der ins Spiel gebrachte Zeitaufwand.

Das Aufräumen der temporären Datein kann z. B. mittels eines
auto_append_file gestalltet werden und macht keinerlei Mühen.



Oder aber ist es vielleicht doch lohnenswert schlichtweg auf den Header
Content-Length zu verzichten und nicht ganz standardkonform zu sein ;)


Gruß aus Berlin!
eddi