search

tbaddade / redaxo_url

REDAXO 5 AddOn zur URL-Generierung für eigene AddOns (ehemals Url Control, ehemals Frau Schultze)
MIT License
46 stars 22 forks source link

DB-Index auf `rex_url_generator_url.url` - für bessere Performance in Übersichtsseiten #296

Open alxndr-w opened 4 months ago

alxndr-w commented 4 months ago

Ich konnte die Performance der Datenbank-Abfragen bei der Darstellung eines Verzeichnis-Liste um 33% verbessern, indem das Feld rex_url_generator_url.url ein Indexfeld bekommt.

Leider ist es mit ->ensureIndex(new rex_sql_index('url', ['url'])) nicht getan, da man hier dem DB-text-Feld nicht die Länge mitgeben kann, z.B. 191 oder 250.

edit: https://saturncloud.io/blog/what-is-the-maximum-length-of-a-url-in-different-browsers/

gharlan commented 4 months ago

Ist es denn überhaupt nötig, dass das Feld vom Typ TEXT ist? Wäre nicht VARCHAR passender?

alxndr-w commented 4 months ago

Bis eben dachte ich, varchar() wäre auf max. 191 (ehem 255) begrenzt. Jetzt habe ich beim googlen gerade gelernt, dass bis zu 65,535 bytes (16,383 chars) möglich sind.

Ich kann nur sagen, 191 wäre zu kurz in einigen Anwendungsfällen.

gharlan commented 4 months ago

Der Redaxo-Core nutzt 191 fast nirgends, sondern nach wie vor 255 (weswegen utf8mb4 erst ab MySQL 5.7 vom Core unterstützt wird). Nur YForm nutzt konsequent 191 (wodurch es utf8mb4 auch in MySQL 5.6 unterstützen kann).

Aber 255 würde dann eventuell auch nicht reichen bei manchen URLs?

VARCHARs mit größeren Längen, da weiß ich bisher auch immer nicht so recht, wann die sinnvoll sind zu nutzen im Vergleich zu TEXT. Und ich weiß auch nicht, bis zu welcher Varchar-Länge Indexe ohne Längenbegrenzung möglich wären. Müsste man sich nochmal weiter einlesen.

Meint ihr denn, dass z.b. VARCHAR(400) ok wäre? Oder welche Länge meint ihr müsste es mindestens sein, um nicht Probleme zu bekommen bei realen URLs?

Vielleicht ist TEXT dann aber hier doch auch tatsächlich sinnvoll. Im Core hatte ich bisher auf die Längen-Begrenzung bei den Indexen verzichtet, weil es bisher keinen Bedarf dafür gab. Wenn es aber den Bedarf gibt, können wir schon überlegen, das zu ergänzen. Wobei es dann auch in ydeploy nachgezogen werden müsste, dass YDeploy dazu die Migrationen passend erstellt etc..

skerbis commented 4 months ago

Folgende, maximale URL-Längen gelten für häufig verwendete Browser. Da alle diese Browser noch einen nennenswerten Marktanteil haben, muss man sich als Webseitenbetreiber auf den kleinsten, gemeinsamen Nenner festlegen und seine URLs auf 2.083 Zeichen in der Länge beschränken.

Microsoft Internet Explorer: 2.083 Zeichen Microsoft Edge: 2.083 Zeichen Google Chrome: 32.779 Zeichen Mozilla Firefox: mehr als 64.000 Zeichen Apple Safari: mehr als 64.000 Zeichen Google Android: 8.192 Zeichen

lt.: https://www.sistrix.de/frag-sistrix/seo-grundlagen/urls/url-laenge

alxndr-w commented 4 months ago

In einem Projekt mit 150 URLs ist genau eine dabei, die 200 überschritten hat (230), das ist wirklich eine Ausnahme.

URLs, die 100 Zeichen überschritten haben, finde ich schon grenzwertig.

Ich wäre auch einverstanden damit, wenn url die bei 255 oder 400 abschneidet.

Soweit ich verstanden habe, kann man eben den Index selbst nochmal begrenzen und das habe ich gemacht, mit entsprechenden Problemen das zu deployen - in diesem issue geht es mir um Performance bei vielen einzelnen Querys.

alxndr-w commented 4 months ago

@skerbis habe ich oben auch bereits verlinkt 🙂

alxndr-w commented 4 weeks ago

https://github.com/tbaddade/redaxo_url/pull/116/files#diff-19e3c84c1b3ce87245588ae6ee7791fe3b94c98a8f955ea3e89f9f5865144ca0L53-R55

@TobiasKrais du hattest den Index hier entfernt, gab es dafür Gründe? Die Performance wurde scheinbar dadurch schlechter, als mit. Zumindest habe ich ein Projekt, das das zeigt und ein Index helfen würde.

TobiasKrais commented 4 weeks ago

Ich weiß es nicht mehr, kann aber sagen, dass ich damals nicht so viel Ahnung von Indizes hatte wie heute. Wenn die Spalte in einem WHERE auftaucht, sollte der Index wieder hinzugefügt werden.