nicht angemeldet
Performancefrage zu imagecreate
Hallo,
Images (jpg + gif) sollen per Formular-Upload in einem Verzeichnis
gespeichert werden. Der Image-Name wird in einer MySqL-DB gespeichert. Je noch Bedarf soll die Grafik in zwei Größen (width, height) angezeigt werden.
Es bieten sich mir zwei Lösungsmöglichkeiten an:
1. Direkt nach dem Upload werden von der "Original-Grafik" zwei Kopien in den jeweiligen Zielgrößen gezogen (imagecreate) und ebenfalls in dem Verzeichnis gespeichert. Die Dateiname der Kopien werden mit Größenangaben in der DB gespeichert.
Vorteil dieser Methode:
- Grafiken stehen beim Aufruf sofort zur Verfügung
Nachteil:
- Im Verzeichnis liegen mehrere Ausfertigungen der gleichen Grafik
(Speicherplatzverbrauch) - In den Datenbanktabelle brauche ich mehrere Spalten
(name,width,height)für jede Ausfertigung (Übersichtlichkeit) - Wird einmal eine bestimmte (zusätzliche) Grafik-Größe benötigt,
steht sie nicht zur Verfügung. (Mangelnde Flexibilität)
2. Die Originaldatei wird im Verzeichnis gerspeichert, der Dateiname in der Datenbank. Beim Aufruf wird eine Kopie der Originaldatei gezogen und in der gewünschten Göße eingefügt.
Vorteile:
- Abspeicherung nur einer Grafik im Verzeichnis
- Übersichsichtliche Datenbanktabelle
- Eine Kopie kann in der jeweils benötigten Größe erstellt werden
(hohe Flexibilität)
Nachteil.
- Die Grafik steht beim Seitenaufruf noch nicht zur Verfügung.
Zunächst muß die Originaldatei kopiert und dann in der gewünschten
Größe erstellt werden (imagecreate).
Jetzt stehe ich vor der Frage ob Lösung 1 oder 2. Tendenziell würde ich Lösung2 vorziehen, jedoch bin ich mir in der Performance-Frage nicht sicher. Wie sieht das aus, führt Lösung2 zu bedeutenden Geschwindigkeitsverlusten? In der Spitze werden bei einem Seitenaufruf ca. 10 Grafiken auf diese Weise eingefügt.
Bitte sagt mir Eure Meinung. Ich sag schon mal Danke.
Viele Grüße
Frank Dell
-
Hi,
- [...]
Vorteil dieser Methode:
- Grafiken stehen beim Aufruf sofort zur Verfügung
- es werden keine evtl. gigantischen Dateien gespeichert, sondern nur das, was Du brauchst.
- Du hast direkt nach dem Upload Kontrollmöglichkeiten das Aussehen betreffend. (Ist eigentlich der von Dir genannte Vorteil, aber IMHO deutlicher.)
- Die Skalierung muss nur ein Mal durchgeführt werden, nicht bei jeder Nutzung.
Nachteil:
- Im Verzeichnis liegen mehrere Ausfertigungen der gleichen Grafik
(Speicherplatzverbrauch)
Ja. Relativiert sich ggf. wegen obigem Vorteil.
- In den Datenbanktabelle brauche ich mehrere Spalten
(name,width,height)für jede Ausfertigung (Übersichtlichkeit)
Eine Datenbank muss nicht übersichtlich sein, dies ist also kein Faktor. Auch die DB-Performance dürfte bei einem günstigen Layout keinesfalls leiden.
- Wird einmal eine bestimmte (zusätzliche) Grafik-Größe benötigt,
steht sie nicht zur Verfügung. (Mangelnde Flexibilität)
Ja, das ist ein Faktor.
- [...]
Die Vor- und Nachteile dieser Methode sind das Gegenteil der Nach- und Vorteile obiger Methode.
Jetzt stehe ich vor der Frage ob Lösung 1 oder 2.
Wir stehen derzeit vor einem extrem ähnlichen (eigentlich fast identischen) Problem, haben aber keinen Zweifel daran, dass Lösung 1 die zu bevorzugende ist. Das einzige Problem (zumindest bei unserer Nutzung) ist, dass man nicht nachträglich skalieren kann. Solange aber selten bis nie andere Formate gebraucht werden, kann man damit gut leben. Falls es doch gelegentlich (mit schwer planbaren Formaten) nötig wird, müsste die Originaldatei _zusätzllich_ mit abgespeichert werden - Hauptsache, man muss nicht bei jedem Request die äußerst (ressourcen-)teure Bilderskalierung vornehmen.
Allerdings muss ich dazusagen, dass uns der Speicherplatz nicht im geringsten interessiert - wenn's nicht reicht, packen wir halt ein Raid mit ein paar hundert Gigabyte dazu ;-)
Wie sieht das aus, führt Lösung2 zu bedeutenden Geschwindigkeitsverlusten?
Ja, selbstverständlich. Eine Datei auszuliefern kostet den Server praktisch keine messbare Zeit; statt dessen ein Script zu starten, welches die Datei in den Speicher lädt, die Daten analysiert, in ein allgemeingültiges Format umwandelt, eine neue Größe errechnet, die Bilddaten geschickt umwandelt (dies kostet _wahnsinnig_ viel!), zurück in ein spezielles Format umwandelt und ausliefert, ist verdammt teuer.
In der Spitze werden bei einem Seitenaufruf ca. 10 Grafiken auf diese Weise eingefügt.
Waaah. Wenn jede zehnte Seite mal eine solche Grafik wäre, könnte man vielleicht über Methode 2 nachdenken :-)
Bitte sagt mir Eure Meinung. Ich sag schon mal Danke.
Methode 1.
Übrigens: Danke, dass Du nur Meta-Informationen in der DB speicherst, nicht die eigentlichen Grafikdaten :-)
Cheatah
-
Hi Cheatah,
Bitte sagt mir Eure Meinung. Ich sag schon mal Danke.
Methode 1.
Danke für die ausfühliche Auskunft. Also um ehrlich zu sein, hatte ich ja gehofft, daß ich ein paar Fans für die von mier favorisierte Lösung 2 finde. Aber gut, was nicht geht geht eben nicht ;-(
Übrigens: Danke, dass Du nur Meta-Informationen in der DB speicherst, nicht die eigentlichen Grafikdaten :-)
Hm, da Du vermutlich kaum damit rechnest, irgendwann einmal über die Site bzw. zu stolpern, vermute ich ich jetzt mal, daß Du dieses "Danke" als Anhänger einer, nennen wir es mal, "ästhetischen Datenbankarchitektur" gemeint hast.
Über Anfängerfehler bin ich mittlerweile hinaus. Allerdings muß ich gestehen, daß ich "früher" - wann immer das war - auch zu solchen Methoden gegriffen habe.
Also nochmals Danke.
Viele Grüße
Frank Dell-
Hi,
Danke für die ausfühliche Auskunft.
gern geschehen.
Also um ehrlich zu sein, hatte ich ja gehofft, daß ich ein paar Fans für die von mier favorisierte Lösung 2 finde.
Performance ist nur relativ selten eine Meinungsfrage... :-)
Aber gut, was nicht geht geht eben nicht ;-(
Och, es geht schon. Nur ist es nicht empfehlenswert.
Hm, da Du vermutlich kaum damit rechnest, irgendwann einmal über die Site bzw. zu stolpern, vermute ich ich jetzt mal, daß Du dieses "Danke" als Anhänger einer, nennen wir es mal, "ästhetischen Datenbankarchitektur" gemeint hast.
Ja, exakt. Einerseits im Hinblick auf http://www.koehntopp.de/php/databases.html#db-blob, andererseits auch, weil ich aus Erfahrung spreche... Wir hatten bis vor kurzem bei einem recht großen Projekt noch die Bilder in der DB gespeichert - diese Fehlentscheidung trafen wir vor _zwei Jahren_, und wir haben schon nach wenigen Monaten begonnen, das zu ändern zu versuchen :-) (Mittlerweile haben wir es übrigens geschafft, kämpfen aber bisweilen noch immer mit den Nachwehen).
Cheatah
-
- [...]