Indexsuche optimieren

So vermeiden Sie Performanceprobleme bei der Indexsuche

Das Problem:

Gerade auf größeren Websites kommt es immer wieder vor, dass die Indexsuche den Server so stark belastet, dass dieser zusammenbricht. Aber auch bei kleineren Seiten kann eine Suchabfrage unnötig lange dauern. Grund ist meistens eine riesig große Tabelle mit dem Namen "index_rel"

Frage ist nun: Warum wird diese Tabelle so groß (Teilweise mehrere Millionen Einträge)?
Vor allem 2 Tabellenfelder sind hierfür verantwortlich: phash und wid

phash ist der Hash-Wert, der sich aus Werten wie Seiten-ID (&id=), typeNum (&type=), Spach-ID (&L=), Mount-Point (&MP), FE-Gruppen und weiteren GET-Parametern zusammensetzt. Die weiteren Parameter erzeugen dann bei einer gecachten Content-Ausgabe noch einen cHash-Wert, der wiederum vom Encryption-Key abhängig ist.

wid ist eine ID für die Verknüpfung mit der Tabelle "index_words". Pro Wort gibt es hier einen Eintrag. Dabei ist ein Wort mit Satzzeichen am Ende ein anderes Wort als ein alleinstehendes Wort. So könnte z.B. das Wort "Beispiel" sowohl als "Beispiel" als auch als "Beispiel." oder "Beispiel;" in der Datenbank stehen.

Pro Wort und phash Wert wird nun eine Zeile in die Tabelle index_rel geschrieben. Hat also eine Seite z.B. 100 unterschiedliche Wörter wären in der Tabelle "index_rel" schon 100 Zeilen. Ändert sich nur ein Parameter, so dass der pHash-Wert sich ändert, werden pro Änderung wieder 100 Zeilen zur Tabelle hinzugefügt.

Lösung:

Das Einzige, dass jetzt helfen kann, ist eine Reduzierung der GET-Parameter, die zu einem neuen pHash-Wert führen und eine Beschränkung auf weniger indizierte Wörter auf einer Seite, vor allem wenn die Wörter sich auf der Seite regelmässig ändern (z.B. LIST- & LATEST-Ansicht bei tt_news).

Hier ein paar Beispiele:

• Bei einem Kalender würde ein Suchmaschinenroboter eigentlich endlos nach hinten und vorne blättern. Der Kalender könnte aber auch so programmiert werden, dass z.B. nur Jahre von z.B. 2000-2010 möglich sind.
• Bei Parametern, die am Inhalt nichts ändern (z.B. anderes Layout bei gleichem Inhalt) könnte ein Cookie anstatt eines GET-Parameters verwendet werden
• Bei einer Bildergallerie könnten vielleicht die Seiten komplett aus der Suche herausgenommen werden, wenn sich bei dem unterschiedlichen Links nur ein Bild ändert, aber keine indizierbaren Texte vorhanden sind.
• Bei der Extension tt_news sollte keine backPid verwendet werden, da ansonsten zu jeder backPid und zu jeder News Einträge in die "index_rel"-Tabelle gemacht werden. Hätten Sie 1000 Seiten mit der LATEST-Ansicht und 1000 News und durchschnittlich 100 verschiedene Wörter pro News, dann würden ca. 100.000.000 Zeilen in der DB gespeichert!
  Die backPid können Sie im TypoScript mit

TypoScript

deaktivieren. Anstatt dem dynamisch generierten Zurück-Button in der SINGLE-Ansicht könnte dann ein Zurück-Link mit JavaScript gemacht werden:

Javascript

• Listenansichten sollten grundsätzlich von der Indizierung ausgeschlossen werden. Entweder man setzt mit den Seiteneigenschaften gleich die gesamte Seite auf "Nicht suchen" oder man definiert die Marker für Such-Beginn & Such-Ende so, dass die Listen nicht indiziert werden. Sie könnten z.B. den Content-Marker auf den Seiten mit den Listen so machen:

TypoScript