Wie viele gleichzeitige ZIP-Vorgänge sind möglich?

[prowler]

Der Titel fragt es ja bereits.

Und zwar möchte ich eine PHP-Seite bauen, auf der User mehrere Bilder gleichzeitig packen und downloaden können. Wo liegen die Grenzen bei Linux bzw. Apache? Kriegt der Server das gebacken oder kann man allgemeine sagen dass nur eine bestimmte Anzahl an Pack-Operationen gestattet werden sollte?

Ich kann mir vorstellen, dass bei hundert Usern, die sich was packen lassen, der Server arge Probleme bekommt. Oder irre ich mich da?

 

[Dr. Glastonbury]

Moin,
die Kiste wird halt immer langsamer... du kannst natürlich versuchen, die prozesse jeweils mit geringerer priorität zu starten, entsprechend mehr Prozesse können laufen, ehe die Kiste an überlastung erlahmt, aber wann schluss ist hängt letztlich vom Prozessor und Arbeitsspeicher ab...

 

[rolle]

Was sind das für zu packende Bilder? Sollten das z.B. JPEGs sein, dann kannst Du die Komprimierung im Normalfall beim Packen komplett weglassen, da sich die Bilder dann eh kaum mehr kleiner machen lassen. Das spart dann massiv Rechenzeit.

 

[prowler]

Der User soll einfach nur die Möglichkeit haben, mehrere Bilder auf einmal als zip runterzuladen. Die Bilder selbst sollen also nicht komprimiert werden.

Wie kann ich denn die Prozess-Priorität beeinflussen? Geht das denn mit php?

 

[gropiuskalle]

Nein, das ist einfach eine Sache der Prozesssteuerung des Systems selbst.

man nice

 

[Anonymous]

Der User soll einfach nur die Möglichkeit haben, mehrere Bilder auf einmal als zip runterzuladen. Die Bilder selbst sollen also nicht komprimiert werden.

Ich hab ja nun überhaupt keine Ahnung was da für Hardware dahinter steht. Aber ich vermute mal mit reiner Reklementierung der Prozesspriorität von zip ist das nicht immer und überall zu lösen. Je Hardware und Konfiguration und nach dem was für Optionen bei zip verwendet werden, wie groß die Bilder sind und wie viele User gleichzeit ihre Bilder Zippen und downloaden und vieles andere mehr, irgendwo wird beim Steigern der Auslastung zwangsläufig irgendwann ein Flaschenhals auftreten. Die wichtigste Frage ist dann, wo ist dieser zu erwarten?
Das können enorme Probleme auftreten wenn es die IO-Last an den Platten betrifft oder der Speicher der dann womöglich noch anfängt zu swappen. Solange nur die CPUn permanet auf 100% Last hängen oder im besten Fall auch nur mal der Webserver oder die Netzleitung blockieren ist es halb so schlimm.

Du solltest dir mal anschauen was du im Webserver maximal an Datenverbindungen freigegeben hast, dann abschätzen wie hoch der durchschnittliche und maximale Anteil an solchen Downloads bezogen auf Serververbindungen sein könnte. Dann musst du am besten selbst etwas testen, indem du selbst definierte typische Zip- und Downloadlast erzeugst. Dabei die Last an den Datenplatten und die Speicherauslastung beobachten. Wenn du beim weiteren steigern der Last feststellst, dass der Speicher gerade anfängt zu swappen, oder die Plattenlast in Nähe von permanent über 95% kommt, dann ist dort die absolute Obergrenze erreicht, die du erlauben darfst. Sobald du die Last etwas absenkst, sollte alles wieder im Lot laufen. Laufen allerdings nur die CPUs hoch, ohne das der Speicher oder Platten dabei oben anschlagen, dann kannst du mit renice oder nice die Zipprozesse etwas bremsen und gut is.

robi

 

[Dr. Glastonbury]

Je nachdem, ob sich die User zu dem Dienst anmelden müssen, wäre auch eine Queue denkbar... also so, dass maximal 3 packprozesse gleichzeitig laufen und wer zuerst kommt malt zuerst -> sprich wenn 100 Anfragen in der Queue stehen, dann müssen eben die am Ende so lange warten bis sie dran sind und können das Archiv erst ne halbe Stunde später laden...

 

[panamajo]

Sollten das z.B. JPEGs sein, dann kannst Du die Komprimierung im Normalfall beim Packen komplett weglassen, da sich die Bilder dann eh kaum mehr kleiner machen lassen. Das spart dann massiv Rechenzeit.

Absolut richtig, die Dateigröße des Archivs variiert bei Dateien im JPEG Format im Promillebereich bei CPU Last Größenordnung 10 zu Gunsten unkomprimiert.
Gleiches gilt für MP3, andere komprimierte Bildformate wie GIF, PNG und Videoformate.

Die Bilder selbst sollen also nicht komprimiert werden.

Wie gesagt, die CPU Last lässt sich durch kompressionlose Archivierung minimieren. Wieviele gleichzeitige Komressionvorgänge ein System packt lässt sich mit Apache Bench (ab bzw. ab2) ermitteln.

Ich würde jedoch nicht zip als Archivformat wählen sondern wahlweise .rar oder .tar (AFAIK kommt die UN*X Version von zip immer noch nicht mit UTF-8 klar, außerdem ist das Handling einfacher).