Dyn. Bildgenierung - Frage der Serverperformance?

[Lodi]

Moin Gemeinde!

Bisher hab ich bei dem kleinen Online-Shop (PHP/MySQL) immer auf die dynamische Generierung von Thumbnails beim Aufrufen der jeweiligen Shopseite gesetzt.

Heisst also, physisch liegt dem Shop pro Artikel nur ein großes Detail-Bild vor, welches dann, je nachdem wo man gerade ist, z.B. auf einer Kategorien-Seite (mehrere Artikel auf einmal), per GD-Lib runtergerechnet und an den Browser gesendet wird.

Nun hat mich aber mein Kollege (eingeschworener PERL-Programmierer) zum Stutzen gebracht: beim von ihm programmierten universell einsetzbaren und kommerziellen CMS (mit Shop und allen möglichen Spielereien) werden beim Hinzufügen eines Artikels (o.ä., z.B. News mit Vorschaubild etc.) gleich beim Einstellen die benötigten Thumbnails generiert und physisch gespeichert, so daß dies nur einmal geschieht.

Begründen tut er dies damit, daß eine dynamische Generierung bei jedem Seitenaufruf den Server viel zu stark belasten würde.

Der Nachteil der Sache, zumindest IMHO, liegt auf der Hand: man muss Änderungen an der Struktur des CMS (speziell neue Thumbnail-Größen) für alle Artikel durchführen, bevor online was angezeigt wird.

Bei "meiner" Variante änder ich einfach die Bildgröße im Script, und alles funzt. Ich fahre damit auch wunderbar, kann mich über Performance-Einbrüche oder längere Ladezeiten nicht beklagen.


Was meint ihr? Zieht das Argument des PERLi's? Ich könnte mir ja vorstellen, daß es an der Anzahl der Bilder liegt, die auf eine Seite generiert werden muss. Wenn das ne ganze Menge sind, und dann noch mehrere User gleichzeitg im Shop rumsurfen...

Ist jetzt keine existenzielle Frage, aber würde mich mal interessieren, wie ihr das seht. Ich hab der Sache, wie oben ja beschrieben, bei meinem PHP-Shop keine Beachtung geschenkt.


Tschaui erstmal,
Jens

[wahsaga]

Re: Dyn. Bildgenierung - Frage der Serverperformance?

Original geschrieben von Lodi
Begründen tut er dies damit, daß eine dynamische Generierung bei jedem Seitenaufruf den Server viel zu stark belasten würde.

natürlich hat er vollkommen recht.

ein thumb, das jedes mal gleich aussieht, trotzdem bei jedem seitenaufruf neu zu generieren, ist ziemlich unsinnig, unter performance-gesichtspunkten.

Der Nachteil der Sache, zumindest IMHO, liegt auf der Hand: man muss Änderungen an der Struktur des CMS (speziell neue Thumbnail-Größen) für alle Artikel durchführen, bevor online was angezeigt wird.

ach komm, wie oft soll denn das deiner meinung nach vorkommen, dass die thumbnail-größen geändert werden? das ist doch wohl nichts, was man jeden tag macht, oder?

[rythms]

Alternative:
Du hast ein Script, dass abfragt ob thumbs existieren, wenn ja benutzt es diese, wenn nein, erstellt es neue und speichert sie.
Das Script wird bei der Artikelansicht aufgerufen.

Vorteile:
- Weiterhin erstellst du die thumbs nur einmal
- Keine Platzverschwendung für nicht angeschaute artikel
- wenn du eine nuee größe willst, löscht du einfach alle thumbs, legst die neue größe im script fest und lässt sie nach und nach neu erstellen.

Nachteile:
- Die Benutzer, bei denen die Thumbs erstellt werden, müssen etwas länger warten

[Lodi]

Re: Re: Dyn. Bildgenierung - Frage der Serverperformance?

Original geschrieben von wahsaga
ach komm, wie oft soll denn das deiner meinung nach vorkommen, dass die thumbnail-größen geändert werden? das ist doch wohl nichts, was man jeden tag macht, oder?

Das nicht, zumindest auf meinen Shop bezogen.

Oben genanntes CMS kommt jedoch bei vielen Projekten der Firma zum Einsatz, wo auch verschieden große Thumbnails und vor allem in den verschiedensten Größen benötigt werden. Also banal gesagt "klitzekleines Thumbnail, kleines Thumbnail, 50%-der-Originalgröße-Thumbnail"

Um da universell zu bleiben und nicht (im Extremfall) 10 Bilder pro Artikel physisch zu speichern, dachte ich mir halt, es wäre vorteilhafter einfach jedes Mal das Thumbnail-Erzeuge-Script einzubinden, mit entsprechender Größen-Parameter-Übergabe.

Aber ihr habt schon recht, auch ohne das ganze praktisch zu testen ist mir klar, daß diese Variante wesentlich performancelastiger ist.

Deswegen hab ich mich gegenüber meinem Kollegen mit "guten Ratschlägen" auch zurückgehalten
Der hat 'n weng mehr Erfahrung bezüglich dieser Sachen als ich.


Danke für Eure Antworten, hab mich belehren lassen