serious-cool

Moin,

ich stehe vor einer Entscheidung:
Wann lasse ich Thumbnails generieren?

1.Möglichkeit:
Direkt beim speichern der Datei werden vom Model alle Presets in das Dateisystem geschrieben.
Vorteil: Einmal Systemlast erzeugen, dann für immer Ruhe haben.
Nachteil: Werden die Presets geändert, verfallen praktisch alle Thumbnails.
Nachteil: Bei 20000 Bilddateien wird der Speicherverbrauch merklich.

2. Möglichkeit:
Dynamische Erzeugung durch die Getter-Action bei Aufruf:
Der Thumbnail wird auf Abruf nach dem angeforderten Preset erzeugt, an den Clienten gesendet und verworfen.
Vorteil: Weniger Speicherplatz nötig.
Nachteil: höhere Systemlast.

3. Möglichkeit:
Der Thumbnail wird wie in Möglichkeit zwei erzeugt aber nicht verworfen sondern auf der Dateibene abeglegt.
Vorteil: Nur der nötige Speicherplatz wird gebraucht.
Nachteil/Vorteil? Systemlast?

Welche Methode würdet Ihr nehemen?

Hintergrundinfo: Da ich den Speicherort offen lassen möchte und eine AccessChecks laufen werden die Dateien immer über einen Getter geliefert.

__________________
Ein Klauenhammer ist kein Schraubendreher, auch wenn beide das Problem ,,Schraube-Wand" bidirektional lösen können.

Mister Ad

dsentker

Das kommt immer auf den Anwendungsfall an.
Vielleicht liegt hier schon der Fehler. Ein Model schreibt nicht, sondern bildet nur Datenssätze ab. Eine Datenbank ist dem Model völlig unbekannt.

__________________

serious-cool

Die Anwendung soll eben universal werden ; ) von der Steuerung von Produktbildern bis zum Fotoalbum einer Comunity muss mein Filemanager erstal alles abkönnen.



Offtopic:
Nicht im Yii Framework, dort sellt das Model die Methoden zum speichern von Datenbankeinträgen bereit.
Dies finde ich sehr sinnvoll da ich in der Action nichts mit der Datenhaltung zu tun haben will,

Mal meine (kurze) Stuktur:
BaseFileModel extends CActiveRecord
(save() Speichert nur den Datensatz)
->ImageFileModel extends BaseFileModel
(save() Speichert auch die Datei und könnte Thumbs erzeugen lassen)
->PdfFileModel extends BaseFileModel
(save() Speichert auch die Datei, kann eine Vorschau über eine andere Servererweiterung erstellen.)

Letztlich gibt es zwischen Möglichkeit eins und den anderen beiden nur die Frage des Ablaufs:
1. $Image -> save()->generatePresets();
2. und 3. Image::model()->findByHash($hash)->deliverPreset('xyz');
Nur dass sich bei 2. und 3. die deliverPreset() Methode etwas unterscheidet.

Das BaseFileModel stellt natürlich alle Methoden zum Lesen und schreiben. Die anderen Models überladen oder überschreiben einige Methoden nach eigenem Bedarf. Eine Miniaturansicht einer PDF wird ja anders generiert als die einer Bilddatei. Auf welche Art und Weise dies geschied muss die Konfiguration entscheiden. Im Controller reicht es den Befehl zum speichern zu geben.

__________________
Ein Klauenhammer ist kein Schraubendreher, auch wenn beide das Problem ,,Schraube-Wand" bidirektional lösen können.

meikel

Prinzipell dann, wenn sich die Vorlage für das Vorschaubild ändert bzw. wenn eine neue Vorlage erstellt wird.

Sollte es sich hierbei um janz normale Bilder handeln, empfehle ich Dir, die Bearbeitung mit imageMagick in der Shell zu erledigen.

dsentker

OT:
Die Actions haben natürlich genausowenig mit der Persistenz zu tun. Aber um deine nächste Frage vorweg zu nehmen: Dafür gibt es Repositories. Ich weiss, dass das Yii Framework (und andere, wie CodeIgniter) gerne mal die Aufgabe der Persistzenz direkt dem Model zu sprechen, was aber m.E. falsch ist (btw: Schau dir doch mal meinen verlinkten Blogartikel in meiner Signatur an).

__________________

serious-cool

Ich hab jetzt nur mal den Model Teil überflogen. Ja, klar Du hast recht. Das Model hat in Yii ja steng genommen auch nichts mit der Persistenz zu tun, diese Fähigkeit erbt es lediglich vom ActiveRecord-dein Repository. Eigentlich müsste ich dann diese Klasse(n) erweitern.

--- Damit wäre meine ursprüngliche Frage aber noch nicht beantwortet---

__________________
Ein Klauenhammer ist kein Schraubendreher, auch wenn beide das Problem ,,Schraube-Wand" bidirektional lösen können.

fireweasel

Wenn die LibGD im Spiel ist, immer an der Stelle, wo das plötzliche Beenden des Scripts wegen Speichermangel den wenigsten Schaden anrichtet oder abgefangen werden kann (letzeres ist allerdings schwierig).

Und ausgehend von der Annahme, dass die Vorschau- und Original-Grafiken öfter angezeigt als bearbeitet werden, ist es am sinnvollsten die Thumbnails dann zu erzeugen, wenn die Originalgrafik erstellt oder geändert wurde.

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.

ChrisvA

Vielleicht hilft es auch mal den Gesichtspunkt der Rechenlast/ des Speicherverbrauchs zu berücksichtigen:
Würde es der Server ohne Probleme schaffen die Thumbnails live nach Methode 2 auszuliefern, oder würde da zu massiven Performance Einbrüchen führen?
Hat der Server genügend Festplatte um alle Thumbnails abzuspeichern (Methode 1)?
Gibt es einzelne Thumbnails, die besonders häufig gebraucht werden, oder werde alle in etwa gleich oft benötigt?
Falls es Thumbnails gibt, die oft benötigt werden, könnte man diese Cachen und die seltenen dann erst erzeugen, wenn man sie braucht.

meikel

Die Frage beantwortet doch der gesunde Menschenverstand:
wenn der User nach dem Klick mehr als 1 sec. warten muß, bis sich Dein Parser durch alle PHP-Instanzen gequält hat, machst Du was falsch.

Wenn Du aus dicken Bildchen kleine Vorschaubilder erstellen willst, nimm das:
http://www.imagemagick.org/script/convert.php

serious-cool

Zumindest auf meinem Server ist sowohl die Rechenleistung als auch der Speicherplatz mehr als ausreichend vorhanden. Es steht allerdings offen wo das Modul später überall verwendet wird.
Wenn ich mir ChrisvAs Einwurf, mit dem Skriptabbruch so ansehe, werde ich die Erzeugung in der Getter-Action anstoßen und der Getter-Action einen Parameter übergeben der die Lebensdauer steuert. So können z.B. Produktbilder dauerhaft abgelegt werden, während das Fotoalbum von TeilnehmerIII erst auf Abruf generiert wird. Wenn dann das Skript warum auch immer ausfällt geht nichts wichtiges kaputt..

__________________
Ein Klauenhammer ist kein Schraubendreher, auch wenn beide das Problem ,,Schraube-Wand" bidirektional lösen können.