phpBB.de

Da ich einige Performanceprobleme in meinem Forum habe, bin ich nun dabei, die meistgenutzten Seiten zu verbessern. An 1. Stelle war da die album_thumbnail.php.

Diese Datei ist meiner Meinung nach unnötig. Denn sie generiert bei jedem einzelnen Vorschaubild eine Datenbankabfrage.

Bei den kleinen Vorschaubildern hielt ich das für quatsch, weshalb ich das mal eben verändert habe.

Ein Beispiel:
Das Vorschaubild wurde bisher mit dieser Adresse generiert:
www.maxrev.de/album_thumbnail.php?pic_id=1225

Wenn man nun eine Kategorie im Album aufgemacht hat, dann liest das Script aus der Datenbank die lustigen IDs der Bilder aus und generiert die Adresse für die Bilder.

Nun damit aber das Bild dargestellt werden kann liest jedes einzelne Bild nocheinmal in der Datenbank aus, welchen Bildernamen es hat. Das macht dann pro Albumseite mindestens 12 Datenbankabfragen (=12 Vorschaubilder).

Der zweite Nachteil ist, dass ein Browser die Bilder nicht zwischenspeichert. Und bei jedem Besuch die Bilder neu lädt. Also wenn jemand von einer Seite zur anderen wechselt verursacht das immer wieder aufs neue Last(!).

Nun habe ich das geändert. Beim 1. Abrufen wird auch der Dateiname ermittelt und ich lese nun den direkten Link zum Bild aus:
http://www.maxrev.de/album_mod/upload/c ... 015e7f.jpg

Vorteile:
- Bilder laden nicht immer wieder neu
- die Bilder können direkt verlinkt werden (auch in Beiträgen)
- die Datenbank wird enorm entlastet

Nachteile:
- die Bilder können direkt verlinkt werden (auch auf fremden Seiten = Traffic)
- es könnte sein, dass das Thumbnail nicht da ist, obwohl der Link ja in der Datenbank ist. Im Originalcode wurde in diesem Fall automatisch ein neues Vorschaubild generiert. Der Cache muss dann im ACP per Hand erneuert werden. (musste ich aber noch nie machen, ich wüsste auch nicht warum ein Bild auf einmal gelöscht sein sollte?!)

Die großen Bilder habe ich erstmal so gelassen, obwohl man dort das gleiche verwirklichen könnte.

Dazu öffnet man die album_hierarchy_sql.php und sucht nach diesem: in der gleichen zeile direkt nach "p.pic_id," setzt man nun das ein: Und das: ersetzt man mit dem: Das macht man nun für jeden Block einmal (also recent, highest rated & random). Insgesamt also 4 Mal.

Ihr glaubt nicht was das den Server beruhigt. Bei mir wurde im Monat März 2006 diese Datei 500.000 Mal aufgerufen. Damit spare ich also jetzt im Monat 500.000 Datenbankabfragen. Nicht schlecht oder

EDIT:
Wenn ich mir meine Statistik aus Februar ansehe und dabei sehe, dass album_pic auf Platz 2 steht, werde ich wohl auch da etwas dran ändern: Das spart dann wieder ca. 250.000 Datenbankabfragen pro Monat. Der einzige Nachteil ist dann nur noch der Trafficdiebstahl. Dem kann man ja bekannterweise per .htacess Herr werden.

Kontrolliert Eure Statistik, ich könnte wetten, dass es bei Euch auch nicht anders aussieht.

Dafür muss man nur in der album_showpage.php nach dem suchen: ersetzen gegen: EDIT:

Auslastung vor dem Umbau:
[ externes Bild ]

Auslastung nach dem Umbau:
[ externes Bild ]

Hört sich interessant an!

Bei welcher Version hast Du das gemacht?

Und das Vorschaubild ist dann immer schon da, oder nur bei den Bildern, die nach dem Umbau geuppt wurden?

Das Problem mit dem Bilder verlinken kann man ja per .htaccess lösen.

Es ist immer da. Ich habe noch etwas dazu editiert wegen der album_showpage. Die Version weiß ich gerade nicht, aber die ist meines Wissens nach nie geupdatet worden oder?

Die Änderung entlastet enorm. Warum mir das nicht schon vorher eingefallen ist.

Ob die Änderung sogar meine Gesamtperformance ausgemacht hat, kann ich in drei Tagen sagen.

EDIT:

Jetzt setze ich noch einen drauf. Im Gegensatz zu vorher spart man sogar Traffic, denn wenn ein User einmal die Startseite im Album öffnet, dann lädt er die Bilder (sie werden in seinem Cache zwischengespeichert), wenn er nun weiter surft und zurück auf die Startseite im Album kommt, dann lädt er die Bilder nicht nochmal. Vorher wurden ALLE Bilder neu geladen. Das gleiche gilt für jede Kategorie oder Seite im Album.

Viel Traffic!

Ja, ist wirklich schnell, obwohl mom nur 7 Gäste online waren.

Ich warte mal Deinen "Bericht" in ein paar Tagen ab.

Bei mir sind es nur ca. 9.500 Abfragen pro Monat (album_thumbnail.php) = 0,3%

ich halte dann mal meine aktuelle Kurve fest:
[ externes Bild ]

Hallo,


ich sehe den ganz gravierenden Nachteil da, wo man mal den Cache mit den Thumbnails löschen musste - GD-Version udgl. Oder wenn man die Einstellungen für die Thumbs ändern will, muss man, um diese Änderungen tatsächlich zum Tragen zu bringen, den AlbumCache leeren.
Nimmt man die Änderungen, wird niemals das Thumbnail neu generiert werden.

Wo die Änderungen wirklich nützlich sind, ist in den Blöcken (recent, random, high rate)

mgutt hat geschrieben:Der Cache muss dann im ACP per Hand erneuert werden.

Wo geht das genau?
Ich finde da nur was, um den Cache zu leeren.


Ist also erst dann nützlich, wenn man sich selber sicher ist, dass man nie an dem Cache der Thumbs herumfummeln wird.

Du hast Recht. Der Mod hat diese Funktion nicht. Aber welchen Sinn macht es den Cache zu löschen? Ich habe das am Anfang zwei mal gemacht, weil ich mir nicht sicher war, welche Größe ich bevorzuge. Und wenn sich die GD-Einstellungen ändern, dann könnte man meinen Mod von Hand rückgänig machen.

Oder es geht auch anders. Man könnte eine if Abfrage einbauen.

Wenn Cachfile da, dann nichts, sonst Funktionsaufruf und Cachefile erstellen.

Soll ich das gerade schreiben? Ich denke nicht, dass das schwierig ist.

EDIT: Tatsächlich ist es auch unlogisch, dass Recent, Random, etc. überhaupt immer wieder prüft, dass ein Cachebild da ist. Aber bei dem Clownspack wundert mich nichts, da es mit einigen kleinen Fehlern veröffentlicht wurde.

Ich denke das spricht für sich:
[ externes Bild ]

Diese Nacht habe ich mit dem Neuaufbau meines Suchindexes angefangen, daher steht der im Moment auf Dauerlast. Aber trotzdem sehr zufriedenstellend

Nun ja, die Spitzen sind weniger geworden, die allgemeine Last aber fast gleich.

Wie sieht es bei den Seitengenerierungszeiten aus, falls Du das bei Dir drin hast?

PageGeneration ist 0,5 Sekunden (!) schneller geworden.

Vorher ist der Server alle zwei Tage abgestürzt. Soll heißen, weiße Seite und nichts ging mehr. Bisher läuft er wie geschmiert. Nur da ich den Suchindex jetzt neu aufbauen lasse und dass 2 Tage dauert läuft der jetzt noch auf voller Last. Was aber ganz gut zu erkennen ist, dass nicht nur die Spitzen weggefallen sind, sondern auch in der Regel die Auslastung unter 500% bleibt.

Wir haben ja Zeit. Warten wir noch einen Monat, dann zeige ich Dir mal die alten Verlaufkurven im Vergleich zu den neuen

Ich merke den Gewinn in jedem Fall. Die User auch. Die sind froh wieder zu spammen was das Zeug hält (wir haben so einen Spambeitrag und da ging zeitweise gar nichts mehr).