Automatik für Suchindex

[rightvision]

Automatische Aktualsierung des Suchindex nach Seitenaufruf im Frontend unterbinden!!
Nach jedem Seitenaufruf belegt mysqld für ca. 20-40 Sekunden über 100% CPU !!! Für große Seiten (wie haben 1,3 Mio Einträge in tl_search_index) ist das untragbar, da oftmals Backend und auch Frontend Timeout. So etwas kann man eigentlich nur über eine CRON-JOB machen. Die Datenbanken sind ok, Ergebnis ist unter MariaDB und MySQL identisch. Contao V3.22.

[rightvision]

Ergänzung: Im Cluster macht die Aktuailisierung der Suche übrigens noch weniger Sinn.... Ein DB Cluster und eine Dateisystem (gluster oder rsync, unison..). Das stellt die Architekur der automatischen Aktualiserung aus unserer Sicht völlig in Frage.

[aschempp]

Hört sich nach einem Feature für https://github.com/terminal42/contao-deferred_search_index an :-)

[rightvision]

Eine Erweiterung mit Abhängigkeit bis 2.11.2 stable macht bei 3.2.2 wohl eher wenig Sinn - oder hat das schon jemand getestet? Sorgt das Modul denn dafür, dass die Automatik im Core deaktiviert wird?

[aschempp]

Nein bisher macht das Modul das nicht so. Könnte aber jemand erweitern, der die Zeit dazu hat ;-)

[Zeromax]

+1

[dmolineus]

+1 dass die Suche entkoppelt werden kann/ über eine API aufrufbar ist. Siehe #6183

[rightvision]

Ich könnte meinem Kunden ohne großen Aufwand sagen, dass er den Suchindex per Backend neu aufbauen muss, wenn er Änderungen vornimmt. Aber ich muss dringend das automatische Update über die Frontendfunktion abschalten können. Wir hatten nach einer Woche Laufzeit der Seite 2,8 Mio Suchworte im Index und das Update durch den Frontendprozess führt zu unzähligen "waiting for table lock" und damit irgendwann zu Timeouts. Nachdem ich tl_search und tl_search_index entleert habe, rennt die Seite wieder.

[Zeromax]

@aschempp wirklich erst für 3.3.0?
Aus meiner Sicht ist das ein Bug der in der LTS behoben werden sollte. Oder es gibt ein Patch für die 3.2 damit bin ich dann auch zufrieden ;)

[Toflar]

@Zeromax das ist sicher kein Bug.

[Zeromax]

@Toflar das ist Ansichtssache. Aber wenn aufgrund einer Automatischen Indizierung die Seite für 20 bis 40 Sekunden nicht erreichbar ist. Ist das eine "Fehlfunktion" in Contao und somit ein Bug.

Aber egal. Ich werde die Änderungen dann für mich eben in die LTS version portieren.

[rightvision]

Kein Bug :-) Sowas sollte ich mal meinen Kunden erzählen, die täglich zwischen 1.000 und 4.000 Bestellungen über ihre Webseite abwickeln. Da bedeutet jede Sekunde Ausfall Code-Red !!

[Toflar]

Es ist Ansichtssache, richtig. Meine Ansicht: Definitiv kein Bug. :)
Wir haben hier keine fehlerhafte Funktion, sondern eine sinnvolle Funktion die aktuell fehlt. Sie muss hinzugefügt werden und ist somit ein Feature. Ein Feature kann per Definition nicht in einer Maintenance-Version mitgeliefert werden und ist deshalb korrekt dem Milestone 3.3.0 zugewiesen.
Aber das Core-Team soll das entscheiden.

[andreasisaak]

@Toflar

Ich denke deine Ansicht wäre eine andere wenn du einen Kunden hast der dir die Hölle heiß machen würde sobald seine Seite wegen zuvieler Daten nicht ereichbar wäre ;)

[Toflar]

Nein, wäre sie sicher nicht.
Wir haben einen klaren Release-Zyklus und klare Versionierungsvorgaben und ich und andere Agenturen (inkl. dir ;-)) verlassen uns darauf, dass diese eingehalten werden.
Wenn der Kunde etwas ausserhalb dieser Vorgaben will, so gibt es genügend Optionen für Erweiterungen und die Partner-Liste ist lang.
Die Situation ist m.M.n. sonnenklar. Es ist ein Feature und kein Bug. Aber wie gesagt: Das Core-Team entscheidet und ich werde jetzt auch nichts mehr dazu sagen. :-)

[Toflar]

@rightvision ist der Content geheim oder gäbe es die Möglichkeit zu Testzwecken an einen Dump der Suchtabellen zu kommen?

[discordier]

This might gain some speed (untested):

core/system/modules/core/library/Contao/Search.php

Line 307 in 2dd402a

$objDatabase->prepare("INSERT INTO tl_search_index (pid, word, relevance, language) VALUES " . implode(", ", $arrKeys))

    // Insert values
    $objDatabase->prepare("
    ALTER TABLE tl_search_index DISABLE KEYS;
    INSERT INTO tl_search_index (pid, word, relevance, language) VALUES " . implode(", ", $arrKeys) .
'; ALTER TABLE tl_search_index ENABLE KEYS;')
                    ->execute($arrValues);

[leofeyer]

Wie besprochen werden die Seiten in cab4ded nicht mehr direkt indiziert, sondern mittels einer verzögerten Ajax-Anfrage (analog zum Command-Scheduler).

[aschempp]

Warum müssen wir dazu das fe_page Template anpassen? Können wir nicht einfach die TL_BODY globale benutzen?

[leofeyer]

Ja, können wir. Geändert in a90a355.

[rightvision]

Eine der Seiten ist http://www.henstedt-ulzburg.de. Der große Suchindex stammt aus einem extern eingebundenen Service (ZUFISH = Zuständigkeitsfinder Schleswig-Holstein) unter Rathaus ABC der Dienstleistungen (http://www.henstedt-ulzburg.de/abc-der-dienstleistungen.html). Dump kann ich bei Bedarf liefern.
tl_search: 1388 Einträge, 67 MiB
tl_search_index: 2060105 Einträge, 117 MiB

[Toflar]

@rightvision Ich würde gerne ein paar Performance-Tests durchführen. Wäre cool wenn ich deinen Dump nutzen könnte :)

[rightvision]

Ist machbar - schreib einfach eine Mail an info MeinAccountName . de und wir schauen mal, wo ich das ablege...

[Toflar]

So :)

// Genereller Test
DELETE statement für einen Index (pid) auf tl_search_index
Dauer: 8.9 ms

// Aktuelle Implementation INSERT INTO
Einzelne INSERT INTO Statements (getestet: 313 Stück)
Dauer: 44.7 ms

// Test mit DISABLE KEYS vor & ENABLE KEYS nach den einzelnen INSERT INTOs
Einzelne INSERT INTO Statements (getestet: 313 Stück)
Dauer: 16.0 s

// Test mit Bulk Insert
Bulk INSERT INTO Statement
Dauer: 8.2 ms

Zusammenfassung: Ich sehe keinen Grund, warum bei dieser Datenmenge (110 MB in tl_search_index) @rightvision's DB so lange braucht. Wie man sieht hat's bei mir mit DELETE und 313 INSERT INTOs ca. 50 ms gedauert. DISABLE KEYS & ENABLE KEYS ist Blödsinn, weil das Neuaufbauen 16 Sekunden dauert. Allerdings könnte man mit einem Bulk Insert nochmal eine Optimierung erzielen.

[leofeyer]

Wir hatten ja zuerst auch ein Bulk-Insert, oder?

[Toflar]

Phu, wann? Mumble? :D