[Modul: Galerie] Dateibasierte Bilderabfrage bewirkt Serverlast

[k00ni]

Hallo,
wir haben von einem unserer Administratoren erfahren, dass das Aufrufen des \"Tool\"-Linkes sehr lange dauert. Wir haben zur Zeit 14846 Bilder online, die ca. 875 MB belegen. Dann noch ca. 13.400 Thumbs und 3xxx Zooms. Es dauert ca. 20 Sekunden, bis der die Seite läd.
Ich gehe davon aus, dass der Server langsam ins Schwitzen gerät, da in einem Ordner alle Bilder abgelegt werden. Es wird per Script auf Dateiebene die Anzahl der Bilder gezählt und die Gesamtgröße auf dem Datenträger bestimmt. Da liegt der Flaschhals.
An sich wäre es ja nicht das Ding, mal 20 Sekunden zu warten. Aber wie wäre es, wenn man dies auf die Datenbank verlagert? Ich würde das Zählen von Bildern beim Löschen und Anlegen einbauen. Damit entlastet man den Server. Möglich wäre es auch, wenn man ein SELECT COUNT (id) über alle Bilddatensätze drüberrutschen lässt.
Ideen dazu?

[Powie]

Naja.... Datenbank und was real existiert kann enorm voneinander abweichen. Es geht an der Stelle ja wirklich nicht drum einfach nur die Bilder in der DB zu zählen, sondern real wirklich zu wissen wieviel Speicher wirklich auf der Platte benutzt wird. Können ja eventuell auch Files dort liegen zu denen es keine DB Einträge mehr gibt. Vor allem die ZOOM/Thumb Files lassen sich nicht in der DB zählen/messen.
Bei mir lädt das ohne merkliche Verzögerung:
Bilder     923 Files - 211.178,25 kByte
Thumb-Nails    1582 Files - 4.507,56 kByte
Zoom-Files    1137 Files - 90.596,67 kByte
Im Import Verzeichnis    2 Files - 4,08 kByte
Ganz abgesehen von den Ursachen, bei solchen Projekten mit Daten in diesen Größenordnungen ist man auf shared Webspace immer am falschen Platz. Da gehört ein Dedi. Server hin!

[k00ni]

Hallo,
dass es bei dir etwas schneller läd ist klar, du hast ja auch 10 mal weniger Bilder als wir. /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />
So wie es ausschaut, können wir da nicht mehr viel optimieren. Aber könnte man nicht hier die is_file-Überprüfung rausnehmen, um es etwas zu pushen ?
 

while ($datei = readdir($fp)) {
 if (is_file(\"$pimg_dir_zoom/$datei\")) {
  $files = $files +1;
  $fsize = $fsize+filesize(\"$pimg_dir_zoom/$datei\");
 }
}

 
 
Denn eigentlich liegt ja in so einem Ordner nicht viel mehr als Bilderdateien.
Dann habe ich noch eine andere Frage: Laut dem Beispiel für readdir von php.net sieht ein Verzeichnisdurchlauf so aus:
 

/* Das ist der korrekte Weg, ein Verzeichnis zu durchlaufen. */
   while (false !== ($file = readdir($handle))) {
       echo \"$file\\n\";
   }
   /* Dies ist der FALSCHE Weg, ein Verzeichnis zu durchlaufen. */
   while ($file = readdir($handle)) {
       echo \"$file\\n\";
   }

 
 
Wird hier der erste oder zweite Weg von dir genommen, Powie? Schaut mir nach dem zweiten aus, da du ja das Filehandle mit dem read-dir vergleichst. Ist nur eine Verständisfrage, da ich nicht genau was, wo hier der Unterschied sein soll.
 
Grüße

[Powie]

das is_file() kann man nicht weglassen, man erhält sonst eine Fehlermeldung bei Verzeichnissen. Meine Variante ist eine Symbiose aus beiden /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />

[k00ni]

Aber die meisten haben doch dort keine weiteren Verzeichnisse drin. Könnte man ja auch einfach unterdrücken /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />

[Powie]

zwei hast du immer !!
.
..
 
 /uploads/emoticons/icon_e_wink.gif.c059000ae48ff64afa53be0962c021f2.gif\" alt=\":wink:\" />

[k00ni]

Mit Punkten kann ich umgehen.  /uploads/emoticons/icon_e_biggrin.gif.1a84f5257b36e14b36d04985314f877f.gif\" alt=\":-D\" /> Na mal schauen was wir da machen. Danke erstmal für die Tipps.
Anbei, die Ordner thumb und zoom sind alle bei uns nur mit Bildern gefüllt...  /uploads/emoticons/icon_e_sad.gif.cc8ba2b6b966c5e020020efa47702aab.gif\" alt=\":(\" />

Wird hier der erste oder zweite Weg von dir genommen, Powie? [/quote]
Der zweite, falsche Weg.

Ist nur eine Verständisfrage, da ich nicht genau was, wo hier der Unterschied sein soll.[/quote]
Im ersten, korrekten Durchlauf wird auch auf den korrekten Typ geprüft; der Test ist Typsicher.

Aber wie wäre es, wenn man dies auf die Datenbank verlagert?[/quote]
Man könnte die Bilder als BLOB in die Datenbank ablegen und trotzdem im Dateisystem vorhalten. Dann kann man die Metadaten ebenfalls in einer Datenbank vorhalten (bestenfalls in einer anderen Tabelle als die Bilder). So könnte man, wenn man nur Metainformationen beziehen will, diese aus der Datenbank beziehen und müsste nich die sehr teuren Dateisystemoperationen verwenden. Wird nun auf ein Bild zugegriffen, kann ein Skript die Daten aus der Datenbank in das Dateisystem schreiben, wo diese dann gecacht werden können.

[k00ni]

Man könnte die Bilder als BLOB in die Datenbank ablegen und trotzdem im Dateisystem vorhalten. Dann kann man die Metadaten ebenfalls in einer Datenbank vorhalten (bestenfalls in einer anderen Tabelle als die Bilder). So könnte man, wenn man nur Metainformationen beziehen will, diese aus der Datenbank beziehen und müsste nich die sehr teuren Dateisystemoperationen verwenden. Wird nun auf ein Bild zugegriffen, kann ein Skript die Daten aus der Datenbank in das Dateisystem schreiben, wo diese dann gecacht werden können.[/quote]
Nein, die Bilder wollte ich nicht in die Datenbank reinlegen. Ich meinte eher nur das ich dort ablege, wieviele Bilder (Original, Zoom, Thumbs) wir haben und vielleicht noch die Dateigröße. War nur eine fixe Idee, um den Server etwas zu entlasten. Denn ich denke, wenn der 14.000 Dateien durchknallen muss, dann geht das schon etwas auf die Performance.
Was du da beschrieben hast klingt interessant. Hast du dazu ein paar Links mit weiterführenden Informationen?

http://www.phpbuilder.com/columns/florian19991014.php3\" rel=\"external nofollow\">http://www.phpbuilder.com/columns/florian19991014.php3
Ich will dir die Nachteile aber gar nicht verschweigen: MySQL kann BLOB nicht fragmentarisch bearbeiten, bedeutet, Du kannst mit einigen Funktionen nicht auf BLOB zugreifen. Zudem ist es nicht sinnvoll, BLOB und Metadaten in die gleiche Tabelle zu legen - bei einem Full Count über die Daten wird dann auch immer über die BLOB iteriert. Deswegen solltest Du die Daten aufteilen.
Ein kaum beachteter aber wesenelticher Vorteil von BLOB liegt darin, dass Du bei einem Datenbank auch immer gleich die BLOB mitsicherst: Die Dumps werden zwar groß, aber auch konsistent.
Theoretisch müsste man auch BLOB mit AES in der Datenbank verschlüsseln können. Habe ich aber noch nie getestet.
Zur Praxisrelevanz:
Ein FOAF hat sowas mal für ein größeres Lexikonprojekt gemacht - mit einigen hunderttausend Bildern und Artikeln in verschiedenen Revisionen.

[Powie]

Im Forum mach ich das ja sogar so mit den Anhängen. Funktioniert problemlos, ist aber kritisch bei der Einstellung von mysql (packet_size) . Für die Galerie aber wär mir das zu hoher Aufwand gewesen, der Grossteil der Files ist ja dort nur aus Cache Gründen vorhanden.

[k00ni]

Also für uns stellt sich erstmal nicht die Frage nach einer Neuentwicklung /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" /> Das von dir aufgezeigte System Statler, scheint zwar dafür bestimmt super geeignet, aber würde auch mit einem großen Haufen Arbeit verbunden sein.
Was könnte man denn am bestehenden System (pGalerie) ändern, damit sie \"etwas\" performanter wird. Ich meine, man könnte die Funktionalität für die Ermittlung der Dateianzahl und -größe anpassen. Weiterhin ein paar Wartungs-Update-Statements von bspw. der index.php in den ACP verlagern. Was fällt euch noch ein? Vielleicht auch an den Einstellungen für den Apache oder der php.ini.
 
Grüße

Also für uns stellt sich erstmal nicht die Frage nach einer Neuentwicklung [biggrins] Das von dir aufgezeigte System Statler, scheint zwar dafür bestimmt super geeignet, aber würde auch mit einem großen Haufen Arbeit verbunden sein.[/quote]
Wie Powie bereits schrieb: Ein ähnliches System gibt es innerhalb der PScripte bereits.

Was könnte man denn am bestehenden System (pGalerie) ändern, damit sie \"etwas\" performanter wird.[/quote]
Ich habe mir das mal angeschaut:

 
vs.

 
 
Ergibt:

Files: 4096
File Size: 2097152000
real    0m0.073s
user    0m0.020s
sys     0m0.040s

 
vs.

Files: 4096
File Size: 2097152000
real    0m0.063s
user    0m0.024s
sys     0m0.032s

 
 
Variante 2 ist demnach bei 4096 Dateien a 500kB (2GB) 1/5 schneller.

[k00ni]

Danke für das Beispiel, werde das bei uns bestimmt gut einbauen können.
Wie ich sehe, arbeitest du mit \"festen\" Dateitypen, vertraust wo nicht auf das Typsystem von PHP? :ugly:
Solche Zeilen
 

$item           =   (string) \'\';

 
 
bin ich eher aus C# oder Boo gewöhnt. Ist dann der Typ nicht mehr änderbar? Also bleibt dann $item immer ein String?
 
Grüße

Wie ich sehe, arbeitest du mit \\\\\"festen\\\\\" Dateitypen, vertraust wo nicht auf das Typsystem von PHP?[/quote]
Nein. Da es in PHP keine strikte Typisierung gibt, mache ich zumindest am Anfang eines Skripts klar, was ich erwarte. Das hilft ungemein bei späteren Wartungsarbeiten.

Ist dann der Typ nicht mehr änderbar? Also bleibt dann $item immer ein String?[/quote]
Leider ist der Typ weiterhin änderbar.