Wieder mal ein Live-Report aus dem Agenturalltag: Ein Kunde hat das Medien-Repository von unserem CMS bis zum Anschlag ausgenutzt. In diesem digitalen Medien Archiv kann man Bilder Galerien ablegen, die z.T. aus hochauflösenden Fotografien bestehen.
Natürlich werden zur Vorschau Thumbnails verwendet, die gecached werden. Bei einigen der Bilder wurden allerdings keine Thumbnails angezeigt. Besonders dumm an dieser Situation war, dass noch nicht einmal von der GD-Library ein Fehler geworfen wird. Verwendet zum einlesen des Bildes hatten wir imagecreatefromjpeg verwendet - die Thumbnailgrundlage wurde mit imagecreate geschaffen.
An welcher Stelle lag der Hase nun im Pfeffer begraben? Gibt es eine maximale Bildgröße, also ein Maximum an Breite und Höhe des Bildes? Vielleicht eine maximale Fläche? Fragen über Fragen und Dr. Google, mein Freund und Helfer ist bei den Aussentemperaturen auch schon heiß gelaufen. Aber Antworten hatte er nicht.
Bis ich auf diesen ziemlich langen und interessanten Thread mit dem schönen Titel “imagecreatefromjpeg” im Selfhtml-Forum gestoßen bin. Hier wurde berichtet, das die php.ini Einstellung “memory_limit” die Notbremse ziehen könnte.
Die ganzen Berechnungen in allen Ehren, aber so auf das Byte genau kann wohl niemand bestimmen, wie groß ein geladenes Jpeg im von PHP zugeteilten Speicher nun ist oder wird. Schließlich gibt es noch einige Randbedingungen wie Metainfos, die ein paar Byte +- ausmachen können.
Nach einem kleinen Test war aber klar: daran lag es - die Dateien waren mit über 8000×9000 Pixeln viel zu groß für den zugeteilten Arbeitsspeicher. Erst ein ziemlich hohes memory_limit erlaubte, das alle Thumbnails generiert wurden.
Was nun? memory_limit höher einstellen? Auf keinen Fall, irgendwann ist nicht mehr abschätzbar, ob und wie schnell der Arbeitsspeicher des Live-Servers zuläuft. Ein viel zu großes Risiko auf der Live-Maschine! Ausweg: Bilder verkleinern? Ja - gute Idee ;-)
