vBulletin und die diversen Caches

Hier geht es also um die Caches von vBulletin und hier insbesondere den Datastore, der meiner Meinung nach eine sehr wichtig und tragende Rolle einnimmt.

Was ist der Datastore?
Grob gesagt werden im Datastore Ergebnisse von Abfragen gespeichert, die vorher aus anderen Tabellen abgefragt wurden. Der Sinn ist also, die vielen Anfragen der einzelnen Tabellen zu reduzieren, da oft die Antwort "gleich" bleibt und daher direkt den Datastore abzufragen. Somit muss eine Information dann nicht mehr über z.B. 7 Tabellen zusammengesucht werden, sondern steht direkt als fertiges Ergebnis im Datastore und kann mit einer Query abgefragt werden.

Der Haken an der Sache ist nur, dass der Datastore selbst in der Datenbank gespeichert ist. Auch wird dieser nicht einmal abgefragt, um alles zu haben, sondern viele viele Male pro Seitenaufruf.

So, und hier kommen dann schon die eigentlichen Caches, die richtigen Caches ins Spiel: z.B. APC. Ist das aktiviert, dann wird der Datastore nicht in der Datenbank gespeichert, sondern direkt im Hauptspeicher. Dort ist der Zugriff dann natürlich unverhältnismäßig schneller!

Warum sind Caches aber so wichtig?
vBulletin ist so ausgelegt, dass alle Abfragen möglichst kurz und einfach sind. Das hat aber auch den Nachteil, dass zig Datenbankabfragen getätigt werden müssen. Z.B. bei einem Post: Nur Auszugsweise: Die Forenberechtigungen, die Optionen, die Session, der Post selbst, die Signatur, das Avatar, der Username, die Reputation, die ganzen Templates , die für die Anzeige benutzt werden und natürlich jede einzelne Phrase (Platzhalter im Template), denn die stehen auch in der Datenbank. Teilweise (sehr oft) erfolgen diese Abfragen nicht direkt in einer Tabelle sondern mit Joins über mehrere. Daher gibt es auch die internen Caches, die diese Ergebnisse zwischenspeichern.

So ergibt das z.B. auch, dass für eine ganz simple Seite, die wohl jeder von uns rein in HTML erstellen könnte, 75 DB-Anfragen erforderlich sind. Sie Seite /contact-us (ganz unten rechts).

Der Debug von vBulletin:

Informationen zur Fehlersuche


    Seiten-ID: 5
    Übergeordnete ID: 1
    Seitentemplate-ID: 8
    Route-ID: 15
    Seitentyp: custom
    Seitenlayout-ID: 1
    Seitenlayout-Template: screenlayout_1
    Kanal-ID:
    Knoten-ID:
    Datenbankzugriffe: 75 (?)
    AJAX Anfragen: 1
    Facebook aktiv: Nein (Nicht aktiviert oder keine appid & Schlüssel angegeben.)
    Style-ID: 2
    Templates/Renders: 18/25
    CSS Templates: 6
    Current Time: r

So, soviel erst mal. Die anderen "Caches", also Node-Cache und dergleichen, was vBulletin da noch so alles ablegt, kommen später.

Ja und nein, Cache ist hier eben nicht Cache.

Da gibt es die echten Obcode und Object-Caches wie APC und memched, da arbeiten wirklich selbst und autark. Dann gibt es noch die "Caches" in der Datenbank selbst. Das sind aber eben quasi nur "aktuelle Zustände", die hinterlegt werden, damit die nicht bei jedem Zugriff neu berechnet werden müssen. Gleich das Ergebnis zu haben ist halt schneller, als es erst berechnen zu müssen und die Query für den Cache ist schlanker. Muss man sich so vorstellen, dass die Seite eines Threads quasi fertig gerendert als "cache" in der DB gespeichert wird. Dann muss man nur noch den Code abfragen und anzeigen, nicht neu alles zusammenbauen. Hat aber wohl auch den Nachteil, dass es Verzögerungen gibt. Das müssen wir testen, was sinnvoll ist und was nicht. Wenn ich mich nicht irre, dann gibt es die Option auch für Gäste. Also angemeldete User direkt, Gäste mit Cache oder so. Irgendwas war da.

Und dann kommt noch ein weiterer Cache hinzu, der oben noch gar nicht steht (wollte ich schon lange sagen, steht auf meiner "Info für Alex-Liste", vergesse es aber immer wieder) und an dem auf jeden Fall was gemacht werden muss: Der qCache von MySQL.

Nur kurz: Du verwendest aktuell einen sehr hohen Key-Buffer (glaube 2GB), das ist gut, aber... Gut für MyISAM-Tabellen, das Forum verwendet aber InnoDB (4 kleine MyISAM, 2 Memory und der Rest InnoDB) Also hier muss man ansetzen, aber dazu braucht es detaillierte Daten aller laufenden Dienste und Datenbanken auf dem Server. Es bringt nichts, den Key-Buffer einfach um 1GB zu reduzieren und den qCache um 1GB zu erhöhen. Kommt drauf an, welche anderen Datenbanken da noch auf dem Server sind welche Storage Engine die verwenden und wie viel Platz deren Indexe einnehmen. (Dazu aber dann mehr in einem eigenen Thema) Ebenso anderes Thema, den Server aufräumen. Denn auch die Db-Sicherungen belegen die Speicher, auch wenn die gar nicht verwendet werden, sowie die alten Tabellen aus vb4 und älter bzw. ehemalige Plugins. Dein Forum hier hat 50% mehr Tabellen als mein original vb5 Aber wie gesagt, das gibt eigene Themen im Bereich Hosting, gehört hier nicht wirklich er.

Ansonsten, die ganzen Caches, vor allem die echten bzw. qCache, reduzieren die Anzahl der Anfragen in der Regel nicht, denn gestellt werden müssen die ja. Der Unterschied ist nur, dass MySQL sie dann nicht selbst "berechnen" und dafür auf die Festplatte zugreifen muss, sondern sagen kann "Die Antwort liegt hier im Memory". Ist quasi wie bei HTTP, wo ein Request gestellt wird und dann 200 oder 403 kommen kann. Der Request ist da, nur der Server muss einem reagieren und ausliefern und einmal "nicht".

Und, gehört ja auch irgendwie mit zum Cache, auch wenn nicht vBulletin. Schiebe mal bitte einen Zugang zur APC.php in das Root vom Testforum (als Symlink, eventuell Zugangsdaten in der apc.php hinterlegen). Ich muss mal sehen, was da so hinterlegt / gespeichert wird.

Nachtrag: Verwirrend, ja, das auf jeden Fall und schlicht auch zu viel meiner Meinung nach. Wäre der Core besser geschrieben, dann bräuchte es das ganze auch nicht.

So, habe gerade nicht viel Zeit, aber mal soviel dazu.

"Soll heissen, viele Queries bedeuten nicht auch automatisch langsam...."

Das ist korrekt, wenn dennoch nicht optimal. vbullertin setzt sehr viele Queries ab und diese teilweise mehrfach auf einer Seite (Das meldet selbst der vbulletin-eigene Debug-Modus). Klar kann das gecached werden, dennoch ist es ein zusätzlicher Zugriff. Die Query muss ja erst gesendet werden, damit dann MySQL entscheiden kann, was damit ist. I/O wird nur bedingt entlastet, denn die Anfrage wird an MySQL gesendet. Dort erfolgt dann die Entscheidung, ob die Daten neu aus der Datenbank gelesen oder aus dem Cache genommen werden Die Anfrage ist also da, nur die Verarbeitung vielleicht nicht. Der Cache kann, wenn vom System so vorgesehen, aus dem RAM bedient werden. Aber eigentlich sollten unnütze Anfragen einfach entfernt werden. Und hier kommt eben auch zum Tragen, was oben angesprochen war, dass der MySQL-Cache hier auf dem System zu klein ist.

Ebenso müssen für ein effizientes Caching die Queries auch effizient sein und das sind viele dank "SELECT * FROM x" nicht. Das kann auch gecached werden, klar, aber da werden Datenmengen in den Cache geschrieben, die gar nicht benötigt werden. Hier im Forum wäre daher eine Cachegröße von > 1GB optimal. Welcher normale Hoster bietet das an?

Dennoch sehe ich es eigentlich so, dass es Aufgabe einer Software ist, die Ressourcen so gering wie möglich zu belasten und nicht die Aufgabe eines Serverdienstes, diese Makel auszugleichen.