Performance-Optimierungen in einem Forum

xAaron hat geschrieben:Prepared Statements

persistente Verbindungen

DB-Partitionierung

gut aufgebaute Indizes

materialisierte Sichten

FullTableScan

mgutt hat geschrieben:

xAaron hat geschrieben:Prepared Statements

Da lese ich mich aktuell ein, aber wirklich viel hilft PS auch nicht, wie mir scheint. Ich meine wie oft nutzt man die gleiche Abfrage, nur mit unterschiedlichen Parametern?

mgutt hat geschrieben:

persistente Verbindungen

Da gehen die Meinungen bei MySQL auseinander. Viele sagen, dass es völlig egal wäre und keinen Vorteil bringt.

mgutt hat geschrieben:

DB-Partitionierung

Wenn das in MySQL 5 mal irgendwann funktioniert, dann vielleicht ja

Ich für meinen Teil spiele ungern mit neuen Sachen herum, die nicht ausreichend getestet wurden. Da gibt es immer wieder gerne mal Sicherheitslecks.

mgutt hat geschrieben:

gut aufgebaute Indizes

Das ist denke ich Standard. Ohne anständige Indizes, kackt ja eigentlich jede DB ziemlich schnell ab.

mgutt hat geschrieben:

materialisierte Sichten

Gibts in MySQL (leider) nicht. Hört sich für mich aber ähnlich wie PS an. Oder ist es das "globale" Ding was ich bei PS vermisse?

mgutt hat geschrieben:

FullTableScan

Sagte mir erst nichts, aber dadurch bin ich überhaupt darauf gekommen, dass es mysql.trace_mode gibt. Da werde ich doch mal schauen, ob es noch was zu optimieren gibt

mgutt hat geschrieben:Geht aber nur zum Teil, weil gewisse Inhalte auch auf Topic-Seiten dynamisch sind (Beitragszähler, Avatar, Signaturen, etc.). Wenn man die dynamischen Inhalte allerdings entfernt oder bei Änderung dieser entsprechenden Punkt die jeweiligen Caches zurücksetzt, könnte man auch eine 100%-tige HTML-Seite ausliefern.

mgutt hat geschrieben:Im Grunde sind es nur die Beitragszähler, die ein Problem verursachen. Weil jedesmal global alle Caches zurückgesetzt werden, wenn ein bestimmter User darin geschrieben hat. Da könnte man meiner Ansicht nach nur noch mit einem zeitversetzten Cache arbeiten, aber ich höre jetzt schon die User schreien "ah mein Wohnort stimmt gar nicht bei diesem Beitrag" "ah meine Beitragsanzahl schankt"

Hast Du nicht mal Lust woanders zu disktuieren, wir weichen stark vom Thema ab

bfs hat geschrieben:Wenn du die Userid als Deteinamen für das Avatar nimmst, kannst du es entweder nicht (browser-)cachen, oder du kriegst ebenfalls die Beschwerden der Nutzer. Dann halt, das sie ihr Avatar geändert haben, aber immernoch das alte sehen.

Im übrigen muss man das nicht lange cachen, keinesfalls Stunden. Wenn du 10 Requests die Minute auf dein Cache-Element hast, dann ist die Chance für einen Cache-Hit schon 90%, wenn du das Teil nur 1 Minute cachst. Jedes weitere Prozent Cache-Hits ist exponential steigendem Gemecker deiner Nutzer verbunden

mgutt hat geschrieben: EDIT:
Ich habe das übrigens noch mal geprüft. Die Hauptlast aller Datenbankabfragen resultiert aus Feeds und der Darstellung der "letzten Beiträge". Die rückwärtige Sortierung von Themen mag MySQL nicht, wenn ich mit mehreren Indexwerten arbeiten muss (in meinem Fall die Filterung nach HostID, ForumID und nach dem Status "keine Kopie"), so dass keine Filterung nach Index, sondern nach Range erfolgt. Ein Index über alle drei Spalten bringt übrigens nichts.

- oft ist es besser, mehrere Abfragen zu tätigen anstatt einer komplexen -> aufdröseln

Synonym hat geschrieben:

- oft ist es besser, mehrere Abfragen zu tätigen anstatt einer komplexen -> aufdröseln

Das ist ein Punkt den ich mir schon lange überlege. Hatte anfangs auch viele kleine Abfragen, die dann aber zu einer großen zusammengebaut. In Bezug auf den qCache scheinen mir aber durchaus mehrere kleine sinnvoller. Nur, kann man das auch irgendwie vernünftig testen und vergleichen?

nerd hat geschrieben:zudem sind rechenoperation in mysql ganz sicher schneller als in php ausgefuehrt.

bloddy newbie hat geschrieben:Wie schaut die Abfrage aus?

SELECT *
FROM topics
WHERE moved_id = 0
AND host_id = 1
ORDER BY last_time DESC
LIMIT 10

if (rand(0,999) == 999) {
  // COUNT()-Abfrage
  if (mysql_affected_rows() > 10) {
    // $last_time wird neu gesetzt (irgendwo in der Config = Cache)
  }
}

SELECT *
FROM topics
WHERE moved_id = 0
AND host_id = 1
AND last_time >= $last_time
ORDER BY last_time DESC
LIMIT 10