Forum lädt sehr langsam durch Datenbankabfragen

  • Affected Version
    WoltLab Suite 5.3

    Moin,

    bei uns tritt das Phänomen auf, dass beim Aufruf der Forenseite unterschiedliche, teilweise erhebliche Ladezeiten je User auftreten. Wir haben mittlerweile herausgefunden, dass diese Ladezeiten im Zusammenhang mit den Boxen "Heiße Themen" und "Letzte Beiträge" zusammenhängen.

    Die Ladezeiten sind deutlich erhöht, wenn ein User viele Beiträge in Themen geschrieben hat, welche in den Boxen angezeigt werden.

    Beispiel:

    Ein User hat in einem Thema X 1.100 Beiträge geschrieben. In dem Thema sind noch 15.000 weitere Beiträge. Das Thema hat rund 500.000 Aufrufe. Die Datenbankabfrage die zur Box "Letzte Beiträge" gehört dauert für ihn 17,3 Sekunden.

    Ein anderer User, der im Thema X 50 Beiträge geschrieben hat erzeugt eine Datenbankabfrage die ungefähr eine Sekunde dauert.

    Das Problem tritt nur auf, wenn die Box aktiviert ist und das entsprechende Thema dort aufgelistet wird.

    Das gleiche Problem besteht auch für die Box "Heiße Themen" (dort hat es bei dem User aus dem Beispiel rund 18 Sekunden gedauert).

    Wir haben zur Identifizierung des Problems den Debug- und Benchmarkmodus aktiviert und dabei sind diese Werte herausgekommen.

    Display Spoiler
    Code
    (SQL Query) SELECT DISTINCT post.userID AS ownPosts,tracked_visit.visitTime,tracked_board_visit.visitTime AS boardVisitTime,user_object_watch.watchID, user_object_watch.notification,like_object.cachedReactions,moderation_queue.queueID AS reportQueueID, thread.* FROM wbb1_thread thread LEFT JOIN wbb1_post post ON (post.threadID = thread.threadID AND post.userID = xxxxxxxx) LEFT JOIN wcf1_tracked_visit tracked_visit ON (tracked_visit.objectTypeID = 209 AND tracked_visit.objectID = thread.threadID AND tracked_visit.userID = xxxxxxxx) LEFT JOIN wcf1_tracked_visit tracked_board_visit ON (tracked_board_visit.objectTypeID = 208 AND tracked_board_visit.objectID = thread.boardID AND tracked_board_visit.userID = xxxxxxxx) LEFT JOIN wcf1_user_object_watch user_object_watch ON (user_object_watch.objectTypeID = 234 AND user_object_watch.userID = xxxxxxxx AND user_object_watch.objectID = thread.threadID) LEFT JOIN wcf1_like_object like_object ON (like_object.objectTypeID = 210 AND like_object.objectID = thread.firstPostID) LEFT JOIN wcf1_moderation_queue moderation_queue ON (moderation_queue.objectTypeID = 232 AND moderation_queue.objectID = thread.firstPostID AND moderation_queue.status <> 2 AND moderation_queue.status <> 3 AND moderation_queue.status <> 4) WHERE thread.threadID IN (?,?,?,?,?) ORDER BY ((((thread.replies + .1) * 50 + thread.views) * 1000000000000) / POWER(UNIX_TIMESTAMP() - thread.time, 1.5)) DESC,thread.time DESC
    Execution time: 18.0145s

    Wir haben besonders die Tabelle wcf1_tracked_visit im Verdacht.

    Wir haben die Boxen erst einmal deaktiviert - in der Hoffnung, dass es eine Möglichkeit gibt oder geben wird um das Problem zu beheben.


    Beste Grüße

    dontonn

    Life of German

    Edited once, last by LifeOfGerman (January 6, 2022 at 2:29 AM).

  • Go to Best Answer
  • Hallo,

    die längere Laufzeit im beschriebenen Fall halte ich noch für nachvollziehbar, da ja tatsächlich erst geprüft werden muss, wie oft/an welchen Stellen User x in einem Thread geschrieben hat. Auch wenn ich persönlich das nicht für die Anzeige "heißer Themen" relevant halte.

    Was mich aber mehr stutzig macht, ist die recht lange Zeit von über 17 Sekunden. Das empfinde ich doch schon als ungewöhnlich viel. Den Zahlen nach deutet es bei Dir ja auf ein größeres Forum hin, evtl. ist der Server (bzw. das Web-Paket) dafür zu schwach? Dann würde natürlich nur ein Umzug helfen. Was natürlich nicht das grundsätzliche Verhalten dieser Boxen ändern würde, aber zumindest diese extreme Ladezeit massiv verkürzen könnte. Ich habe u.a. diese Boxen auch aktiv und derartige "Lastspitzen" noch nie beobachtet. Auch "früher" unter 5.3 und sogar 5.2 nicht.

    Ich kann mich zwar einerseits dunkel erinnern, dass WoltLab zumindest früher die Software selber vor allem für "kleinere und mittlere Foren" empfohlen und als dafür konzipiert genannt hatte und weniger für große Projekte, aber andererseits ist ja auch dieses Support-Forum nicht unbedingt "klein" und hier läuft es recht flüssig. Auch kenne ich andere größere Foren, in denen das durchaus (trotz dieser Boxen) ebenfalls der Fall ist. Die eingesetzte Hardware kann logischerweise viel zu solchen Effekten beitragen, auch wenn diese "Zeitdifferenzen" in Deinem Fall schon sehr krass sind.

    Gruß

    Jörg

    (Jaydee)

  • Moin Jörg,

    Danke für Deine Antwort und die Gedanken dazu. Auf die Box "Heiße Themen" könnten wir tatsächlich verzichten ^^. Aber gerade die Box "Letzte Beiträge" wird gut und gerne genutzt.

    Das Problem tritt tatsächlich nur bei Foren auf, wo man selbst viele Beiträge geschrieben hat. Wenn man zum Beispiel nur 10 Beiträge in dem 16.000 Beiträge Thema geschrieben hat, fallen die Ladezeiten kaum ins Gewicht.

    Wir konnten über das reproduzieren der Datenbankabfragen die Problematik auf die Tabelle wcf1_tracked_visit eingrenzen und verstehen aktuell nicht, wieso diese Tabelle für die Boxen relevant ist. Wenn man die Tabelle aus der Abfrage heraus nimmt erhält man trotzdem das gleiche Ergebnis nur deutlich schneller.

    Unser Webserver liegt auf einem leistungsstarken Rootserver, der keineswegs ausgelastet ist.


    Beste Grüße

    dontonn

  • Ich kann mich zwar einerseits dunkel erinnern, dass WoltLab zumindest früher die Software selber vor allem für "kleinere und mittlere Foren" empfohlen und als dafür konzipiert genannt hatte und weniger für große Projekte

    Ich bedaure, aber da spielt dir dein Gedächtnis einen Streich, so einen Unsinn haben wir zu keinem Zeitpunkt verbreitet. Unsere Software skaliert problemfrei und ist von vorne herein darauf ausgelegt.

  • Ich bedaure, aber da spielt dir dein Gedächtnis einen Streich,

    In dem Fall nicht ganz. Ich wusste, dass ich das vor Jahren schon mal irgendwo gelesen hatte und habe gerade noch mal geforscht. Mindestens bei Wikipedia (ja ich weiß, das Vertrauen ist da bei Einigen nicht so groß) liest man das auch heute noch über die Version 4.x:

    Quote from Wikipedia


    Burning Board 4.0 und 4.1 eignen sich wegen der Einschränkungen der enthaltenen Suchfunktion (MySQLs FULLTEXT) im Auslieferungszustand eher nur für kleine bis mittlere Communitys. Bei größeren Communitys mit mehreren 100.000 Datensätzen nimmt gemäß Woltlab die Geschwindigkeit der Suche stark ab und die Relevanz der Suchergebnisse sinkt. Abhilfe schafft ab Burning Board Version 4.1 eine Elasticsearch-Integration, die Woltlab als kostenpflichtiges Plugin zur Verfügung stellt

    Also diese Aussage muss ja demnach zumindest damals mal von "offizieller Seite" gefallen sein, das werden sich die Autoren kaum aus den Fingern saugen.

    Von "voller Skalierbarkeit" könnte in dem Fall keine Rede sein, denn dabei treten derartige Performance-Einbußen nicht auf (zumindest dürften sie das nicht). .

    Gruß

    Jörg

    (Jaydee)

  • Die Problematik mit der Skalierung des MySQL-FULLTEXT ist aber ein Grundproblem von MySQL und hat nichts mit unserer Software zu tun. Offenbar hat da jemand nur sehr oberflächlich über die Aussagen gelesen, statt den Kern des Problems zu verstehen.

    Ich hatte dazu im letzten Jahr eine ausführliche Erklärung verfasst, warum die Suche von MySQL grundsätzlich nur bedingt skaliert.

    woltlab.com/community/thread/?postID=1868414#post1868414
  • Ja, es stimmt natürlich, dass die "Bremslast" da hauptsächlich bei den technischen Limits von MySQL (und gerade FULLTEXT) liegt.

    Das wurde in dem Artikel glaube ich auch erwähnt.

    Gruß

    Jörg

    (Jaydee)

    • Best Answer
    • Official Post

    In dem Thema sind noch 15.000 weitere Beiträge. Das Thema hat rund 500.000 Aufrufe. Die Datenbankabfrage die zur Box "Letzte Beiträge" gehört dauert für ihn 17,3 Sekunden.

    Vorweg: Die Aufrufe sind nicht relevant, das ist nur eine einzelne Zahl in einer Spalte, dies hat keinen Einfluss auf die Performance. Zum Vergleich, das Thema Smalltalk - Labern, reden, diskutieren... hat aktuell über 53.000 Beiträge bei ca. 3,5 Millionen Aufrufen, trotzdem stellt dies kein Problem dar.

    Die extremen Verzögerungen könnten ein Indiz dafür sein, dass MySQL auf Grund der Konfiguration der Arbeitsspeicher ausgeht und so Daten temporär auf die Festplatte geschrieben werden. Selbst bei SSDs weist dies eine schlechte Performance auf, mit HDDs geht die Performance dann endgültig in den Keller.

    Es könnte helfen, die Abfragen mal mit einem vorangestellt EXPLAIN auszuführen. Damit erhält man von MySQL Angaben zum Query-Plan, mit dem man Flaschenhälse identifizieren kann.

  • Moin,

    vielen Dank! Wir haben kürzlich den MySQL Server neu aufgesetzt und dabei die Einstellung bei innodb-buffer-pool-size nicht gesetzt. Scheinbar wird diese standardmäßig mit 128MB eingestellt - was natürlich viel zu wenig war. Die Abfrage für eine Box hat zwischen 1-2GB benötigt.

    Wir fragen uns, obwohl das Problem nun nicht mehr akut auftritt, ob hier nicht eine Schraube wäre um Ressourcen einzusparen. Die Abfrage der
    Tabelle wcf1_tracked_visit war zur Erfüllung der Aufgabe nicht unbedingt notwendig (auf die Box "Letzte Beiträge" bezogen) und erzeugt bei solchen mächtigen Themen für unnötigen Verbrauch von Arbeitsspeicher. Bei Boxen wie "Heiße Themen" können wir die Abfrage verstehen, sonst aber nicht.

    Vielen Dank für die Hilfe.


    Beste Grüße

    dontonn

  • Die Abfrage der
    Tabelle wcf1_tracked_visit war zur Erfüllung der Aufgabe nicht unbedingt notwendig […]

    Das ist so nicht korrekt, darüber wird ermittelt, ob ein Thema ungelesene Beiträge enthält, dies wird in der Anzeige berücksichtigt.

    Die Abfrage für eine Box hat zwischen 1-2GB benötigt.

    Nicht die Abfrage selbst benötigt so viel Speicher, sondern die zugrunde liegenden Daten bzw. Indizes. MySQLs Performance skaliert sehr stark mit dem verfügbaren Arbeitsspeicher, je weniger dieser zur Verfügung hat ("memory starved"), desto schlechter wird diese. Die Minimalanforderung steigt mit der Menge an Daten bzw. auch der Größe der Indizes.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!