Hohe Serverlast durch Suche nach mehreren Tags

Hier können Probleme und alles andere in Deutscher Sprache gelöst werden.
Post Reply
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

Hallo,

in letzter Zeit schlagen bei mir Anfragen auf, die einige Last erzeugen. Diese beziehen sich zumeist auf ältere Beiträge und suchen nach mehreren Tags:

Code: Select all

https://…/blog/archives/1999/plugin/tag/tag1/tag2/tag3/plugin/tag/tag4
Dabei entsteht eine SQL-Abfrage, die ewig dauert:

Code: Select all

SELECT neg.tag AS tag, count(neg.tag) - 14 AS total
  FROM serendipity_entrytags AS main LEFT JOIN serendipity_entrytags AS neg ON main.entryid = neg.entryid LEFT JOIN serendipity_entrytags AS sub0 ON main.entryid =                sub0.entryid LEFT JOIN serendipity_entrytags AS sub1 ON main.entryid =
  sub1.entryid LEFT JOIN serendipity_entrytags AS sub2 ON main.entryid = sub2.entryid LEFT JOIN
     serendipity_entrytags AS sub3 ON main.entryid = sub3.entryid LEFT JOIN serendipity_entrytags AS sub4 ON main.entryid = sub4.entryid
LEFT JOIN serendipity_entrytags AS        sub5 ON main.entryid = sub5.entryid LEFT JOIN serendipity_entrytags AS sub6 ON main.entryid =
sub6.entryid LEFT JOIN serendipity_entrytags AS sub7 ON main.entryid =
     sub7.entryid LEFT JOIN serendipity_entrytags AS sub8 ON main.entryid = sub8.entryid LEFT JOIN serendipity_entrytags AS sub9 ON
+main.entryid = sub9.entryid LEFT JOIN
     serendipity_entrytags AS sub10 ON main.entryid = sub10.entryid LEFT JOIN serendipity_entrytags AS sub11 ON main.entryid =
sub11.entryid LEFT JOIN serendipity_entrytags
     AS sub12 ON main.entryid = sub12.entryid LEFT JOIN serendipity_entrytags AS sub13 ON main.entryid = sub13.entryid
  WHERE (sub0.tag = 'tag1' AND sub1.tag = 'tag2' AND sub2.tag = 'tag3' AND sub3.tag = 'tag4' AND sub4.tag = 'tag5' AND
sub5.tag = 'tag6' AND sub6.tag =
     'tag7' AND sub7.tag = 'tag8' AND sub8.tag = 'tag9' AND sub9.tag = 'tag10' AND sub10.tag = 'tag11' AND sub11.tag =
'tag12' AND sub12.tag = 'tag' AND
     sub13.tag = 'tag14') AND (neg.tag != 'tag1' AND neg.tag != 'tag2' AND neg.tag != 'tag3' AND neg.tag != 'tag4' AND neg.tag !=
'tag4' AND neg.tag != 'tag5'
     AND neg.tag != 'tag7' AND neg.tag != 'tag8' AND neg.tag != 'tag9' AND neg.tag != 'tag10' AND neg.tag != 'tag11' AND
neg.tag != 'tag12' AND neg.tag !=
     'tag' AND neg.tag != 'tag14')
  GROUP BY neg.tag
  LIMIT 45
Die obige Query benötigte 2494 Sekunden bis zur Beendigung. Da das nicht nur ein Query ist, könnt ihr euch denken, dass der Server manchmal ganz schön ächzt.

Ein Problem erscheint mir, dass plugin/tag mehrfach im Request vorkommt.
Derzeit ist das über einen Eintrag in der .htaccess geblockt:

Code: Select all

RewriteRule plugin/tag/.*/plugin/tag - [F]
Habt ihr ähnliches auf euren Seiten gesehen und wie kann man das eventuell mit S9Y-Mitteln beheben?
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by onli »

Wow, diese SQL-Abfrage sieht ja wirklich übel aus.
Ein Problem erscheint mir, dass plugin/tag mehrfach im Request vorkommt.
Bist du durch die Abfrage durchgestiegen? Doppelt sie da einfach joins über das zweite plugin/tag/tag4?
Habt ihr ähnliches auf euren Seiten gesehen und wie kann man das eventuell mit S9Y-Mitteln beheben?
Ich habe sowas definitiv noch nicht gesehen, hätte das Problem bei mir aber auch nicht bemerkt wenn es nicht wirklich den Blog zu Halten brächte. S9Y-Mittel zum Beheben fällt mir keine ein. Wenn wir gemeinsam das Problem richtig verstehen könnten wir die Situation im Plugincode vielleicht verhindern, also das zweite plugin/tag rausfiltern wenn es wirklich ungewollt ist.

Was mich da ein bisschen irritiert ist der neg.*-Part des Queries. Ob da vll im Plugin über diese Logik Negation umgesetzt wurde, also bestimmte Tags nicht haben zu wollen? Ich bin mit der Pluginlogik leider so gar nicht vertraut.

Ideen:

1. Wir müssten verstehen warum die Situation entsteht und ob das vll gewollt war
2. Dann entweder die Joins/den Query reduzieren
3. Prüfen, ob da indexe fehlen die das ganze beschleunigen können. Manchmal überrascht SQL ja und was wie ein Monsterquery erscheint ist bei richtiger Konfiguration quasi sofort erledigt
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

Ich bin nicht wirklich durch die Anfrage durchgestiegen. Wenn ich mal etwas Zeit habe, will ich die nochmal auseinandernehmen. Aber bislang war das leider nicht der Fall.

Also die Anfragen mit sehr vielen Tags sehe ich in meinem Blog recht häufig. Bislang hat sich der Server jedoch nicht beschwert. Das Freetag-Plugin bekam ja kürzlich ein Update. Aber sofern ich den Code verstehe, kann das kaum der Auslöser sein.

Ein nochmaliger Aufruf von "plugin/tag" nach dem ersten "plugin/tag" erscheint mir in meinem konkreten Fall nicht zielführend. Ich habe im Blog weder "Plugin" noch "Tag" als Tag verwendet. Allerdings kann es durchaus sein, dass andere dies tun. Aber in dem Fall müsste die SQL-Anfrage auch problemlos sein.

Ich werde mir die Query mal anschauen und auch versuchen, den Code zu verstehen. Vielleicht ergibt sich da etwas mehr Aufschluss.
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

Code: Select all

LEFT JOIN serendipity_entrytags
AS sub1 ON main.entryid = sub1.entryid
In der originalen Abfrage sind 14 LEFT JOINs drin. Das dürfte schon ein Problem darstellen. Ich habe testweise mal einige Abfragen mit LEFT JOINs gemacht. Die Ergebniszahl stieg jeweils um den Faktor 7--10. Das Ganze 14-mal bringt schon einiges an Belastung.
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by onli »

Zwischenfrage: Stimmte denn das mit den 2494 Sekunden Laufzeit des Queries? Das wären 40 Minuten, kann nicht stimmen, oder? Welche Datenbank wird denn benutzt? Eine maximale Querylaufzeit zu konfigurieren wäre wohl so oder so eine gute Idee.
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

Das war zumindest die Ausgabe von mtop. Daher gehe ich schon davon aus, dass das stimmt. Auch bei meinen Tests mit LEFT JOIN ist schon bei zwei LEFT JOINs eine Verzögerung zu merken, die pro weiterem LEFT JOIN deutlich ansteigt.

DB ist MySQL als MariaDB in der Version 15.1.
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

Soweit ich das sehe, ermittelt die originale SQL-Abfrage wirklich nur die Beiträge, die zu den Tags passen. Könnte man das nicht folgendermaßen vereinfachen?

Code: Select all

SELECT tag, count(entryid) AS total
          FROM entrytags 
          WHERE tag in (" . $included_tags . ") 
          AND tag not in (" . $excluded_tags . ") GROUP BY tag"
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

Daneben ist mir unklar, warum der Typ von tag immer mal wechselt: Alles innerhalb einer Funktion.
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by onli »

qbi wrote: Wed Feb 01, 2023 3:45 pmKönnte man das nicht folgendermaßen vereinfachen? ...
Das was selected wird weist auf jeden Fall darauf hin.
qbi wrote: Wed Feb 01, 2023 3:52 pm Daneben ist mir unklar, warum der Typ von tag immer mal wechselt:
Hm, der Code switch da ja sauber drüber. Je nachdem was $tag ist macht `getTagCloudQuery` etwas anderes. Wahrscheinlich, weil die Tagcloud mal für viele tags, mal für einzelne tags und manchmal ohne tags erstellt werden muss. Das wäre recht typischer PHP-Code für die alten Plugins.
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

Nur Interessehalber:
Hast du eine Idee, wann das Plugin original geschrieben wurde? Github reicht nur bis 2011. In meinem S9Y-Buch von 2008 ist das auch schon erwähnt. Frühere Vorkommen habe ich bisher nicht gefunden.
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by onli »

Mindestens Dezember 2004, https://sourceforge.net/p/php-blog/mail ... nth=200412 zeigt einen Commit von Garvin am 13.12.:
Log Message:
Directory /cvsroot/php-blog/additional_plugins/serendipity_event_freetag added to the repository
Dass es schon vorher in irgendeiner Form existiert hat würd ich nicht ausschließen.
qbi
Regular
Posts: 37
Joined: Sun Aug 05, 2018 6:52 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by qbi »

onli wrote: Wed Feb 01, 2023 4:54 pmDas wäre recht typischer PHP-Code für die alten Plugins.
Ich überlege gerade, ob ich mich mal an eine Neufassung des Plugins oder eine grundsätzliche Überarbeitung wage. Nachdem ich jetzt längere Zeit über dem Code meditiert habe, glaube ich, dass eine komplette Überarbeitung sinnvoll wäre. Habt ihr neben den Ausführungen im Buch ein paar gute Quellen zur Plugin-Entwicklung für S9Y? Auf was sollte man achten, wo sind Fallstricke etc.?
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Hohe Serverlast durch Suche nach mehreren Tags

Post by onli »

Probier es gerne aus! Es ist allerdings keine ganz leichte Aufgabe. Der neue Code sollte ja wohl Datenbankkompatibel sein und auch Funktionen wie die Integrierung mit dem Seitenleistenplugin unterstützen. Dagegen kann man wahrscheinlich im Backend ein paar Zöpfe abschneiden. Ich bin mit einem ähnlichen Ansinnen bei dem staticpage-Plugin nie weit gekommen (Grundfunktionalität ist einfach, aber es bei allen Anforderungen dann noch hübsch zu machen war zu viel + es gab kein Interesse).
qbi wrote: Thu Feb 02, 2023 10:06 am Habt ihr neben den Ausführungen im Buch ein paar gute Quellen zur Plugin-Entwicklung für S9Y? Auf was sollte man achten, wo sind Fallstricke etc.?
Hm, wohl eher nicht viel. Es gibt https://docs.s9y.org/docs/developers/plugin-api.html. Ich habe ein bisschen in meinen Blog gepackt, https://www.onli-blogging.de/879/Einfue ... eiben.html und https://www.onli-blogging.de/index.php? ... ugins.html, aber das ist jetzt auch uralt.

Komm im Zweifel mit konkreten Fragen am besten ins Gitter, https://gitter.im/s9y/lobby.
Post Reply