Serendipity Forums

Posted: **Sat Jan 28, 2023 8:21 pm**

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?

Posted: **Sun Jan 29, 2023 3:25 pm**

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

Posted: **Mon Jan 30, 2023 1:00 pm**

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.

Posted: **Mon Jan 30, 2023 11:30 pm**

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.

Posted: **Mon Jan 30, 2023 11:36 pm**

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.

Posted: **Tue Jan 31, 2023 9:54 am**

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.

Posted: **Wed Feb 01, 2023 3:45 pm**

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"

Posted: **Wed Feb 01, 2023 3:52 pm**

Daneben ist mir unklar, warum der Typ von tag immer mal wechselt:

Zeile 1559: boolean

Code: Select all

function getTagCloudQuery($sort = '', $tag = false)

Zeile 1566: String
Code: Select all
```
if (is_string($tag)) {
```
Zeile 1572: Array
Code: Select all
```
} else if (is_array($tag)) {
```

Alles innerhalb einer Funktion.

Posted: **Wed Feb 01, 2023 4:54 pm**

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.

Posted: **Wed Feb 01, 2023 5:49 pm**

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.

Posted: **Wed Feb 01, 2023 7:01 pm**

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.

Posted: **Thu Feb 02, 2023 10:06 am**

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.?

Posted: **Thu Feb 02, 2023 4:14 pm**

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.

Serendipity Forums

Hohe Serverlast durch Suche nach mehreren Tags

Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags

Re: Hohe Serverlast durch Suche nach mehreren Tags