Bilder über Skript ausgeben - Performance

[Marko]

Hallo alle

Auf einer viel besuchten Seite, wo die User Bilder hochladen können, werden alle gecachten Thumbnails über ein PHP-Script ausgegeben, mit:

header('Content-type: image/jpeg');

und

readfile(...);

Wieviel schlechter ist das, Performance und Load-Technisch gesehen, als die Links zu den Bildern direkt anzugeben (statt skript.php?image=1 den direkten Pfad zum Bild)?

Mein Gedanke dazu ist: Das File wird sowieso gestreamed, nur wird bei einer Methode das File von php gestreamed, und bei der anderen vom Webserver (Apache). Ich weiss aber faktisch nicht, ob und wieviel langsamer der Weg über php ist.

Hat jemand Erfahrung damit oder kann mich auf hilfreiche Webseiten verweisen?

Vielen lieben Dank,
Marko

[wahsaga]

hi,

Wieviel schlechter ist das, Performance und Load-Technisch gesehen, als die Links zu den Bildern direkt anzugeben (statt skript.php?image=1 den direkten Pfad zum Bild)?

Mach dir klar, was bei beiden Abläufen passiert:

Bei direkt eingebundenen Bildern muss der Server nur nachschauen, gibt's so'ne Bilddatei, Ja? OK, dann lese ich deren Inhalt mal ein, und schick ihn an den Client.

Bei der anderen Methode muss er erst mal eine neue Scriptinstanz starten - also je nach Art der PHP-Einbindung ggf. sogar noch mal ein neuer Prozess.
Dann muss dieses Script erst nach dem Blid suchen, und dann einlesen und an den Client ausgeben.

Mein Gedanke dazu ist: Das File wird sowieso gestreamed,

Wieso gestreamed? In der üblichen Bedeutung von Streaming wohl kaum.

A pro pos Stichwort "Caching", welches du eingangs erwähntest, was du aber wogl nur rein serverseitig meintest - wie sieht's mit clientseitigem Caching aus?
Das kann die Performance einer Anwendung natürlich steigern und den Traffic verringern - aber wenn du mit dem PHP-Script arbeitest, müsstest du das auf HTTP-Ebene selber implementieren - bei statischen Bilddateien hingegen kümmert sich da im allgemeinen der Server schon ganz allein drum.

gruß,
wahsaga

[Marko]

Hallo wahsaga

Mein Gedanke dazu ist: Das File wird sowieso gestreamed,

Wieso gestreamed? In der üblichen Bedeutung von Streaming wohl kaum.

Ich mein mit gestreamed nur eben ausgelesen. Ist ja ein Stream, es wird ja nicht die ganze Datei in einem Zug in den RAM geladen (ausser die Datei ist sehr klein natürlich).

A pro pos Stichwort "Caching", welches du eingangs erwähntest, was du aber wogl nur rein serverseitig meintest - wie sieht's mit clientseitigem Caching aus?
Das kann die Performance einer Anwendung natürlich steigern und den Traffic verringern - aber wenn du mit dem PHP-Script arbeitest, müsstest du das auf HTTP-Ebene selber implementieren - bei statischen Bilddateien hingegen kümmert sich da im allgemeinen der Server schon ganz allein drum.

Gutes Argument, das Clientseitige Caching habe ich nicht bedacht. Ich habe nur vom Serverseitigen Cache geredet.

Vielen Dank,
Marko

[wahsaga]

hi,

Ich mein mit gestreamed nur eben ausgelesen. Ist ja ein Stream, es wird ja nicht die ganze Datei in einem Zug in den RAM geladen (ausser die Datei ist sehr klein natürlich).

Da kennst du readfile aber schlecht :-)
Im Ernst, genau das macht das m.W. - deshalb finden sich in den Nutzerkommentaren im Handbuch und im WWW auch explizite Ersatzfunktionen, die sich selber ums häppchenweise einlesen und flushen kümmern.

gruß,
wahsaga

[Tom]

Hello,

Ich mein mit gestreamed nur eben ausgelesen. Ist ja ein Stream, es wird ja nicht die ganze Datei in einem Zug in den RAM geladen (ausser die Datei ist sehr klein natürlich).

Da kennst du readfile aber schlecht :-)
Im Ernst, genau das macht das m.W. - deshalb finden sich in den Nutzerkommentaren im Handbuch und im WWW auch explizite Ersatzfunktionen, die sich selber ums häppchenweise einlesen und flushen kümmern.

Genau diese unangenehme Eigenschaft von Readfile() habe ich neulich erst beschrieben. Ich muss auf einem rotten Suse-Server, der sich nicht mit seinem Apachen verstehen will (wie leider so oft), PDF-Files über eine PHP-Script ausliefern, weil sonst die IEs streiken...

Man benötigt ca. 2,5 bis 4 x soviel Speicher für das PHP-Script, wie das auszuliefernde File groß ist.

Der Apache liefert auf einem intakten Linux (also nicht Suse) die Files aber blockweise aus, benötigt also nicht für jede Instanz viermal soviel Speicher, wie die Ressource groß ist.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[rob]

Hi!

Man benötigt ca. 2,5 bis 4 x soviel Speicher für das PHP-Script, wie das auszuliefernde File groß ist.

Und das mit dem Speicher könnte ganz schnell zu einem Problem werden.

Wir hatten bei uns mal ein Redaktionsscript für eine Online-Zeitung.

Weil unser "Reporter und Fotograf" zu dumm war, die Bilder, die er mit seiner Digicam gemacht hat, in Photoshop einzuladen und zu verkleinern und weil er ohnehin nicht in der Lage war, einen FTP-Client zu benutzen, gab es im Adminbereich ein Upload-Script.

Der konnte also dort seine Bilder hochladen und per PHP-Script sollten diese dann automatisch resized werden.

Bei den meisten Bildern versagte das Script und ich sollte mir das dann ansehen.

Das Problem lag daran, daß wir einen Account auf einem Shared-Server hatten und das es eine Speicherbegrenzung für PHP-Scripte gab:
Fatal error: Allowed memory size of blablabla bytes exhausted...

Ich glaube, dem Script standen nur 8 MB Speicher (memory_limit, php.ini) zur Verfügung.

Und wenn man jetzt stark komprimierte Bilddateien wie JPEGs hat und diese bearbeiten will, dann ist ganz schnell Ende.
Da hilft es dann auch nichts mehr, wenn man versucht, Speicher freizugeben.

Ich glaube, daß der memory_limit-Defaultwert bei 8 MB liegt.
Das kann natürlich jeder Hoster ändern, aber schätzungsweise werden die meisten Hoster einem Script nicht viel mehr Speicher zugestehen - besonders nicht auf Shared-Servern.

Bei der Bildbearbeitung oder beim Umgang mit größeren PDF-Dateien könnte der Speicher also wirklich zu einem Problem werden.

Schöner Gruß,
rob

[wahsaga]

hi,

Ich glaube, dem Script standen nur 8 MB Speicher (memory_limit, php.ini) zur Verfügung.

Und wenn man jetzt stark komprimierte Bilddateien wie JPEGs hat und diese bearbeiten will, dann ist ganz schnell Ende.

Auf Bild"art" und Komprimierung kommt's dabei kaum an - entscheidend ist die reale Größe des Bildes, also Breite mal Höhe mal Farbtiefe.

gruß,
wahsaga