Die PonyGallery ML ist wie fast alle Komponenten für Joomla! vorwiegend in der Scriptsprache PHP geschrieben. PHP wird serverseitig ausgeführt, d.h. alle Funktionen etc., die in den PHP-Scripten hinterlegt werden, müssen durch den Server, auf dem Eure Seiten liegen, abgearbeitet werden. Das ist anders als z.B. bei JavaScript; JavaScript wird clientseitig ausgeführt, also von Eurer Maschine zuhause abgearbeitet.

Auf das Verhalten von JavaScript kann man ja auch Einfluß nehmen, es z.B. im Browser ausschalten. Das kann man mit PHP nicht! Einfluß auf die grundlegenden PHP-Einstellungen kann man nur direkt auf dem Server nehmen. Und zwar nur, wenn man über administrative Rechte auf dem Server verfügt.

Das hat nichts mit den Admin-Rechten unter Joomla! zu tun. Administrative Rechte oder auch Root-Rechte hat man auf dem Server nur, wenn einem der Server selbst gehört oder es sich um einen angemieteten Root-Server handelt. Alle PHP-relevanten Grundeinstellungen sind in einer Datei auf dem Server gespeichert, die php.ini heißt (wo sich diese Datei befindet, kann man unter System >> System Info >> PHP Info >> Configuration File (php.ini) Path ablesen).

Wie oben erwähnt, kommt man an diese Datei nur ran, wenn man Admin auf dem Server ist. Also in der Regel garnicht. Man kann sich aber anzeigen lassen, welche Einstellungen in der php.ini gemacht wurden. Dazu gibt es mehrere Möglichkeiten: die einfachste ist, im Backend von Joomla! unter System >> System Info >> PHP Info nachzusehen.

Man kann aber auch mit einem Editor eine Datei anlegen, die man z.B. info.php nennt und die folgenden Inhalt hat:

Diese Datei speichert man direkt im Joomla-Verzeichnis auf dem Server ab und ruft sie über den Browser auf. Die Ausgabe unterscheidet sich nur unwesentlich von der PHP-Info aus dem Joomla!-Backend. Auf jeden Fall kann man jetzt sehen, was vom Server-Admin bezüglich PHP alles festgelegt wurde. Und da kommen wir jetzt auf den Upload in der PonyGallery ML zurück.

Egal welchen Upload man in der PonyGallery ML wählt, alle unterliegen - da sie von PHP ausgeführt werden - mehr oder weniger diesen Einstellungen. Und davon gibt es eine Menge, die sich auch noch gegenseitig beinflussen können.

Ich werde im folgenden auf die einzelnen Einstellungen erklärend eingehen, aber vorab noch eine wichtige Bemerkung: im Configuration Manager der PonyGallery ML kann man unter Benutzer-Rechte Einstellungen bezüglich der Anzahl und der Dateigröße der hochzuladenden Bilder machen. Diese Einstellungen betreffen lediglich den Frontend-Upload und sind lediglich dazu gedacht, die User einzuschränken. Die Einstellungen überschreiben aber keinesfalls die oben beschriebenen PHP-Einstellungen. Man kann also dort nicht einfach eine riesige Dateigröße angeben und davon ausgehen, dass das dann auch klappen muß.

Sollte die entsprechende Einstellung in der php.ini bezüglich der Upload-Größe kleiner eingestellt sein, wird die Pony-Einstellung wirkungslos.

Aber jetzt zu den für den Upload relevanten PHP-Einstellungen:

file_uploads:

file_uploads bestimmt, ob überhaupt Dateien über HTTP auf den Server geladen werden dürfen. Steht diese Einstellung auf OFF, geht - was den Upload betrifft - , garnichts.

upload_max_filesize:

upload_max_filesize bestimmt die maximale Größe, die eine hochgeladene Datei haben darf. Normalerweise wird dieser Wert in M angegeben, also in Megabyte. Bei dem Einzelbildupload und beim FTP-Upload in der PonyGallery ML wird dieser Wert für jedes einzelne Bild herangezogen, da sie auch einzeln hochgeladen werden. Beim Batch-Upload hingegen wird die Größe des zip's betrachtet, was demnach schnell an die gesetzten Grenzen stoßen kann. Eigentlich sollte man denken, dass dieser Wert alleine für die uploadbare Größe ausschlaggebend ist. Das ist aber nicht so. Wie gesagt bedingen sich einzelne Einstellungen und wenn man größere Dateien hochladen will, so muß die folgende Einstellung auf upload_max_filesize abgestimmt sein.

post_max_size:

post_max_size bestimmt die maximale Größe von POST-Daten. In der Regel sind Datei-Uploads POST-Daten. Um größere Dateien hochzuladen, muss der Wert größer sein als upload_max_filesize.

memory_limit:

memory_limit bestimmt den Maximalwert des Speichers, den ein Script verbrauchen darf und wird in der Regel in Bytes angegeben. Der Wert sollte höher als derjenige sein, der unter post_max_size eingetragen wurde. Steht der Wert auf -1, ist kein Limit gesetzt. memory_limit ist von besonderer Bedeutung, da man nur näherungsweise absehen kann, wieviel Speicher beim Verarbeiten der Bilder wirklich benötigt wird.

Bei der Größenänderung durch die PonyGallery ML bzw. durch die GD-Bibliotheken kann man für die hochzuladenden Bilder den minimalen Verbrauch an virtuellem Speicher über folgende Formel errechnen:

Breite des Bildes in Pixel * Höhe des Bildes in Pixel * Bittiefe in Byte = Speicherbedarf in Byte

Es sind also die Abmessungen eines Bildes und die Bittiefe, die den Speicherbedarf bestimmen und nicht etwa die Größe des Bildes auf dem Datenträger! Nehmen wir an, wir würden ein Bild mit den Abmessungen 2272 Pixel mal 1704 Pixel und einer Bittiefe von 24 (24 Bit = 3 Byte) durch die Größenänderung jagen, dann ergäbe die Formel (2272 x 1704 x 3 = 11.614.464 Byte) einen Speicherbedarf von über 11 MB! Dazu würde dann auch noch der Speicherbedarf der PHP-Scripte der PonyGallery ML mit etwa 8 MB hinzukommen. Damit sind wir schon nahe an 20 MB Speicherbedarf. Steht memory_limit auf 16 MB ist hier dann bereits Schluss!

Die letzten drei Einstellungen sind also wesentlich für den Dateiupload und sollten im Verhältnis memory_limit > post_max_size > upload_max_filesize stehen. Ist z.B. upload_max_filesize auf 2 M eingestellt, so darf man sich nicht wundern, wenn ein Batch-Upload mit einem zip von 4 MB Größe in die Hose geht, oder?

Aber diese drei Einstellungen sind nicht alleine verantwortlich dafür, ob der Dateiupload klappt. Es gibt eine weitere wichtige Einstellung, die trotz richtiger (großzügiger) Werte bei den drei vorangegangenen Einstellungen alles vermasseln kann:

max_execution_time:

max_execution_time legt die maximale Zeit in Sekunden (bzw. Millisekunden!) fest, die ein Skript laufen darf, bevor der Parser die Ausführung stoppt. Gerade beim Upload großer Batch-Dateien läuft das Script eine ganze Weile, weil die zip-Datei erst hochgeladen werden muss, dann entpackt wird und dann noch die ganzen Kopiervorgänge und die Größenänderung durchgeführt werden.

Kommt dann noch eine langsame Internet-Verbindung hinzu, ist schnell Feierabend. Und da liegt auch der Hase im Pfeffer. Die Scripts der PonyGallery ML werden solange ausgeführt, bis sie an die gesetzten Grenzen der php.ini stoßen. So kommt es manchmal vor, dass einige Dateien aus einem Batch-zip geladen werden und dann plötzlich Schluß ist.

Der Parser (also die Instanz, die die Skripte unter Beachtung der Einstellungen in der php.ini interpretiert) bricht einfach kommentarlos die Aktion des Scripts ab. Wir denken über Möglichkeiten nach, solche Abbrüche zu verhindern, aber das gestaltet sich schwierig.

Sonderfall 1und1

Einen Sonderfall bei den Uploadbeschränkungen stellen diverse Pakete von 1und1 dar. Die oben genannten Einstellungen in der php.ini sind in diesen Paketen absolut ausreichend gesetzt (max_execution_time 50000, max_filesize 8M, memory_limit 40M, post_max_size 8M, upload_max_filesize 20M), sodass es eigentlich nicht zu Abbrüchen kommen sollte.

Trotzdem erscheint beim Upload etwas größerer Bilder (etwa ab 400 KB) eine Fehlermeldung wie "Internal Server Error 500". Diese Fehlermeldung wird im Gegensatz zu den oben behandelten Fehlermeldungen nicht von PHP ausgegeben, sondern vom Server selbst, dem Apachen. Und das heißt, dass in diesem Fall nicht die üblichen Verdächtigen, also die PHP-Einstellungen, die Ursache für den Abbruch sind, sondern die Einstellungen im Apache. Und die greifen unabhängig davon, welche PHP-Einstellungen gesetzt sind.

Laut 1und1-Support gibt es nur drei Ursachen für eine 500-Seite:

1. das Skript startet mehr als 24 Prozesse auf dem Server
2. die Prozessorzeit von 10 Sekunden wird überschritten oder
3. der maximale virtuelle Speicher von 32 MB wird überschritten

zu 1: diese Ursache läßt sich ausschließen, da bei kleineren Bildern der Upload ja funktioniert und bei größeren ja nicht mehr Prozesse gestartet werden...

zu 2: bei der Prozessorzeit handelt es sich um etwas anderes als die max_execution_time! Die Prozessorzeit beschreibt die Zeit, die der Prozessor des Servers mit den Aufgaben beschäftigt ist, welche das Skript gerne von ihm abgearbeitet haben möchte. Dabei sind die 10 Sekunden relativ und beschreiben nur den Ernstfall der Vollauslastung des Prozessors. Demnach wird das Skript terminiert, wenn es den Prozessor länger als 10 Sekunden auf 100 Prozent Auslastung hält. Bei einer 10%-igen Auslastung des Servers über angenommene 2 Sekunden wäre die Prozessorzeit bei 0,2 Sekunden, bei einer 50%-tigen Auslastung über 10 Sekunden wäre die Prozessorzeit bei 5 Sekunden. Demnach ist es mit an Sicherheit grenzender Wahrscheinlichkeit unmöglich, dass dies die Ursache für den Abbruch ist. Denn solange dauert der Vorgang selbst bei großen Bildern nicht und der Upload selber beansprucht kaum Prozessorzeit.

zu 3: die PonyGallery ML nutzt z.Z. ausschließlich die GD- bzw. GD2-Bibliothek für die Manipulation der Bilder; zum Beispiel für die Verkleinerung auf Detail-Bildgröße oder auf Thumbnail-Bildgröße. Die GD funktioniert so leidlich. Die Qualität nimmt merklich ab, wenn man sie benutzt und außerdem benötigt sie enorme Speicher-Ressourcen. Aber sie wird auf fast allen Servern eingesetzt, da sie mittlerweile auch Bestandteil der PHP-Installation ist. Der Speicherbedarf beim Verkleinern der Bilder ist relativ groß und umso größer die Bilder sind, umso mehr steigt er an. Aber dass er bei einem 400-KB-Bild über 32 Mb ansteigen soll, erscheint mit fast unmöglich und trotzdem scheint hier die Ursache des Problems zu liegen.

Und was sagt uns das jetzt? An die Einstellungen des Apache kommt man natürlich noch weniger dran, als an die PHP-Einstellungen. Und nach meinem Kenntnisstand ist dieses Verhalten nur bei 1und1 bekannt und tritt - nach den Schilderungen diverser Benutzer in den einschlägigen Foren - auch bei Uploads anderer Galerien wie Zoom oder ICE regelmäßig auf. Es liegt also nicht an unseren Skripten, sondern vielmehr an 1und1. Die werden aber auch auf Bitte daran nix ändern. Da dieses Verhalten ausschließlich auf den 1und1-Servern auftritt, sehen wir uns auch nicht gezwungen, über unseren Code nachzudenken, nur um das 1und1-Problem zu umgehen. Sicher ist der Upload verbesserungswürdig und auch den Einsatz anderer Bibliotheken zur Bildmanipulation haben wir ins Auge gefasst, aber die PonyGallery ML ist nicht die Ursache des Problems.

Ich hoffe, dass dieser Beitrag ein wenig zum Verständnis der Vorgänge beim Upload durch die PonyGallery ML beiträgt. Wie Ihr seht, sind die Grenzen fast ausschließlich serverseitig gesetzt. Die Galerie hat keinen Einfluß auf die PHP-Einstellungen. Deswegen gibt es ja auch mittlerweile den FTP-Upload, der eigentlich nur noch durch max_execution_time ausgebremst werden kann und so die meisten Fallstricke bei den Einstellungen der php.ini umgeht.

Natürlich gibt es noch viele andere Faktoren, die einen Upload behindern können (wwwrun etc.). Aber darüber ein anderes Mal.

E-Mail (wird nicht veröffentlicht)

Name

Titel

Kommentar
 verbleibende Zeichen

Eintragen