Informationen für eine schlanke, performante Indexsuche [Gelöst]

  • Oliver Thiele Oliver Th...
    Sternenflotten-Admiral
    0 x
    188 Beiträge
    4 Hilfreiche Beiträge
    01. 06. 2007, 12:20

    [b]Das Problem:[/b]
    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.

    [b]Lösung:[/b]
    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 [TS]plugin.tt_news.dontUseBackPid = 1[/TS]
      deaktivieren. Anstatt dem dynamisch generierten Zurück-Button in der SINGLE-Ansicht könnte dann ein Zurück-Link mit JavaScript gemacht werden:
      [HTML]<a href="javascript:history.back()" title="Zur&uuml;ck zur Listenansicht">« Zurück</a>[/HTML]

    • » 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:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = |<!--TYPO3SEARCH_begin--><!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]
      Auf normalen Seiten oder der Single-Ansicht müsste der wrap dann so aussehen:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = <!--TYPO3SEARCH_begin-->|<!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]

    • » Die Druckansicht sollte man möglichst über CSS und nicht über einen Print-Button machen. Wenn man aber dennoch mit einer Print- oder PDF-Darstellung arbeiten will, dann sollten diese Inhalte nicht auch noch indiziert werden. Zum Einen hilft eine geschickte Anordnung der Marker TYPO3SEARCH_begin und TYPO3SEARCH_end, zum Anderen sollte im TypoScript nicht im global gültigem config-Abschnitt index_enable auf 1 gesetzt werden. Wenn dies nicht beachtet wird, hat man für jede typeNum neue Einträge in der "index_rel"-Tabelle!

      Falsch wäre:
      [TS]config {
      index_enable = 1
      index_externals = 1
      }
      page {
      ...
      }[/TS]

      Richtig wäre:
      [TS]page {
      config {
      index_enable = 1
      index_externals = 1
      }
      ...
      }[/TS]


    • » Ein einmal gesetzter Encryption-Key sollte nicht mehr gewechselt werden, da sich ansonsten alle cHash-Werte ändern. Dies würde zu sehr vielen neuen Einträgen in der DB führen. (Zudem kann dies unter Umständen den Pagerank bei Goole zerstören und Abmeldelinks beim Newsletter funktionieren auch nicht mehr).

    • » Wenn TYPO3 Version 4.1+ verwendet wird, sollte man gegebenenfalls die Tabellen "index_..." komplett löschen und mit einem COMPARE im Install-Tool neu anlegen lassen. Wenn die Datenbank InnoDB unterstützt, werden die Tabellen dann auch als InnoDB-Tabellen angelegt. Hier können die Tabellen ausgelesen werden, obwohl vielleicht in diesem Augenblick ein Eintrag geschrieben wird. Die älteren MyISAM-Tabellen werden nämlich während eines Schreibzugriffs komplett gesperrt.

    • » Nach den Optimierungen sollten die Tabellen wenigstens geleert werden, damit die überflüssigen Daten dann auch nicht mehr in der DB liegen bleiben. Danach sollte auch im TYPO3-Backend unter Web->Info->Indexed search->Technical Details überprüft werden, ob die Änderungen zum Erfolg geführt haben, oder ob noch unnötige Einträge vorhanden sind.

    Sollte jemand noch andere Dinge für erwähnenswert halten, dann bitte ich um Rückmeldung.

    Viel Erfolg dann noch mit der performanteren Index-Suche!

    Oliver Thiele


  • 1
  • Oliver Thiele Oliver Th...
    Sternenflotten-Admiral
    0 x
    188 Beiträge
    4 Hilfreiche Beiträge
    13. 12. 2016, 10:53

    [b]Das Problem:[/b]
    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.

    [b]Lösung:[/b]
    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 [TS]plugin.tt_news.dontUseBackPid = 1[/TS]
      deaktivieren. Anstatt dem dynamisch generierten Zurück-Button in der SINGLE-Ansicht könnte dann ein Zurück-Link mit JavaScript gemacht werden:
      [HTML]<a href="javascript:history.back()" title="Zur&uuml;ck zur Listenansicht">« Zurück</a>[/HTML]

    • » 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:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = |<!--TYPO3SEARCH_begin--><!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]
      Auf normalen Seiten oder der Single-Ansicht müsste der wrap dann so aussehen:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = <!--TYPO3SEARCH_begin-->|<!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]

    • » Die Druckansicht sollte man möglichst über CSS und nicht über einen Print-Button machen. Wenn man aber dennoch mit einer Print- oder PDF-Darstellung arbeiten will, dann sollten diese Inhalte nicht auch noch indiziert werden. Zum Einen hilft eine geschickte Anordnung der Marker TYPO3SEARCH_begin und TYPO3SEARCH_end, zum Anderen sollte im TypoScript nicht im global gültigem config-Abschnitt index_enable auf 1 gesetzt werden. Wenn dies nicht beachtet wird, hat man für jede typeNum neue Einträge in der "index_rel"-Tabelle!

      Falsch wäre:
      [TS]config {
      index_enable = 1
      index_externals = 1
      }
      page {
      ...
      }[/TS]

      Richtig wäre:
      [TS]page {
      config {
      index_enable = 1
      index_externals = 1
      }
      ...
      }[/TS]


    • » Ein einmal gesetzter Encryption-Key sollte nicht mehr gewechselt werden, da sich ansonsten alle cHash-Werte ändern. Dies würde zu sehr vielen neuen Einträgen in der DB führen. (Zudem kann dies unter Umständen den Pagerank bei Goole zerstören und Abmeldelinks beim Newsletter funktionieren auch nicht mehr).

    • » Wenn TYPO3 Version 4.1+ verwendet wird, sollte man gegebenenfalls die Tabellen "index_..." komplett löschen und mit einem COMPARE im Install-Tool neu anlegen lassen. Wenn die Datenbank InnoDB unterstützt, werden die Tabellen dann auch als InnoDB-Tabellen angelegt. Hier können die Tabellen ausgelesen werden, obwohl vielleicht in diesem Augenblick ein Eintrag geschrieben wird. Die älteren MyISAM-Tabellen werden nämlich während eines Schreibzugriffs komplett gesperrt.

    • » Nach den Optimierungen sollten die Tabellen wenigstens geleert werden, damit die überflüssigen Daten dann auch nicht mehr in der DB liegen bleiben. Danach sollte auch im TYPO3-Backend unter Web->Info->Indexed search->Technical Details überprüft werden, ob die Änderungen zum Erfolg geführt haben, oder ob noch unnötige Einträge vorhanden sind.

    Sollte jemand noch andere Dinge für erwähnenswert halten, dann bitte ich um Rückmeldung.

    Viel Erfolg dann noch mit der performanteren Index-Suche!

    Oliver Thiele

  • Oliver Thiele Oliver Th...
    Sternenflotten-Admiral
    0 x
    188 Beiträge
    4 Hilfreiche Beiträge
    13. 12. 2016, 11:07

    [b]Das Problem:[/b]
    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.

    [b]Lösung:[/b]
    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 [TS]plugin.tt_news.dontUseBackPid = 1[/TS]
      deaktivieren. Anstatt dem dynamisch generierten Zurück-Button in der SINGLE-Ansicht könnte dann ein Zurück-Link mit JavaScript gemacht werden:
      [HTML]<a href="javascript:history.back()" title="Zur&uuml;ck zur Listenansicht">« Zurück</a>[/HTML]

    • » 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:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = |<!--TYPO3SEARCH_begin--><!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]
      Auf normalen Seiten oder der Single-Ansicht müsste der wrap dann so aussehen:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = <!--TYPO3SEARCH_begin-->|<!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]

    • » Die Druckansicht sollte man möglichst über CSS und nicht über einen Print-Button machen. Wenn man aber dennoch mit einer Print- oder PDF-Darstellung arbeiten will, dann sollten diese Inhalte nicht auch noch indiziert werden. Zum Einen hilft eine geschickte Anordnung der Marker TYPO3SEARCH_begin und TYPO3SEARCH_end, zum Anderen sollte im TypoScript nicht im global gültigem config-Abschnitt index_enable auf 1 gesetzt werden. Wenn dies nicht beachtet wird, hat man für jede typeNum neue Einträge in der "index_rel"-Tabelle!

      Falsch wäre:
      [TS]config {
      index_enable = 1
      index_externals = 1
      }
      page {
      ...
      }[/TS]

      Richtig wäre:
      [TS]page {
      config {
      index_enable = 1
      index_externals = 1
      }
      ...
      }[/TS]


    • » Ein einmal gesetzter Encryption-Key sollte nicht mehr gewechselt werden, da sich ansonsten alle cHash-Werte ändern. Dies würde zu sehr vielen neuen Einträgen in der DB führen. (Zudem kann dies unter Umständen den Pagerank bei Goole zerstören und Abmeldelinks beim Newsletter funktionieren auch nicht mehr).

    • » Wenn TYPO3 Version 4.1+ verwendet wird, sollte man gegebenenfalls die Tabellen "index_..." komplett löschen und mit einem COMPARE im Install-Tool neu anlegen lassen. Wenn die Datenbank InnoDB unterstützt, werden die Tabellen dann auch als InnoDB-Tabellen angelegt. Hier können die Tabellen ausgelesen werden, obwohl vielleicht in diesem Augenblick ein Eintrag geschrieben wird. Die älteren MyISAM-Tabellen werden nämlich während eines Schreibzugriffs komplett gesperrt.

    • » Nach den Optimierungen sollten die Tabellen wenigstens geleert werden, damit die überflüssigen Daten dann auch nicht mehr in der DB liegen bleiben. Danach sollte auch im TYPO3-Backend unter Web->Info->Indexed search->Technical Details überprüft werden, ob die Änderungen zum Erfolg geführt haben, oder ob noch unnötige Einträge vorhanden sind.

    Sollte jemand noch andere Dinge für erwähnenswert halten, dann bitte ich um Rückmeldung.

    Viel Erfolg dann noch mit der performanteren Index-Suche!

    Oliver Thiele

  • Oliver Thiele Oliver Th...
    Sternenflotten-Admiral
    0 x
    188 Beiträge
    4 Hilfreiche Beiträge
    13. 12. 2016, 11:07

    [b]Das Problem:[/b]
    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.

    [b]Lösung:[/b]
    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 [TS]plugin.tt_news.dontUseBackPid = 1[/TS]
      deaktivieren. Anstatt dem dynamisch generierten Zurück-Button in der SINGLE-Ansicht könnte dann ein Zurück-Link mit JavaScript gemacht werden:
      [HTML]<a href="javascript:history.back()" title="Zur&uuml;ck zur Listenansicht">« Zurück</a>[/HTML]

    • » 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:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = |<!--TYPO3SEARCH_begin--><!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]
      Auf normalen Seiten oder der Single-Ansicht müsste der wrap dann so aussehen:
      [TS]page.10.marks.CONTENT_NORMAL = CONTENT
      page.10.marks.CONTENT_NORMAL {
      wrap = <!--TYPO3SEARCH_begin-->|<!--TYPO3SEARCH_end-->
      table = tt_content
      ...
      }[/TS]

    • » Die Druckansicht sollte man möglichst über CSS und nicht über einen Print-Button machen. Wenn man aber dennoch mit einer Print- oder PDF-Darstellung arbeiten will, dann sollten diese Inhalte nicht auch noch indiziert werden. Zum Einen hilft eine geschickte Anordnung der Marker TYPO3SEARCH_begin und TYPO3SEARCH_end, zum Anderen sollte im TypoScript nicht im global gültigem config-Abschnitt index_enable auf 1 gesetzt werden. Wenn dies nicht beachtet wird, hat man für jede typeNum neue Einträge in der "index_rel"-Tabelle!

      Falsch wäre:
      [TS]config {
      index_enable = 1
      index_externals = 1
      }
      page {
      ...
      }[/TS]

      Richtig wäre:
      [TS]page {
      config {
      index_enable = 1
      index_externals = 1
      }
      ...
      }[/TS]


    • » Ein einmal gesetzter Encryption-Key sollte nicht mehr gewechselt werden, da sich ansonsten alle cHash-Werte ändern. Dies würde zu sehr vielen neuen Einträgen in der DB führen. (Zudem kann dies unter Umständen den Pagerank bei Goole zerstören und Abmeldelinks beim Newsletter funktionieren auch nicht mehr).

    • » Wenn TYPO3 Version 4.1+ verwendet wird, sollte man gegebenenfalls die Tabellen "index_..." komplett löschen und mit einem COMPARE im Install-Tool neu anlegen lassen. Wenn die Datenbank InnoDB unterstützt, werden die Tabellen dann auch als InnoDB-Tabellen angelegt. Hier können die Tabellen ausgelesen werden, obwohl vielleicht in diesem Augenblick ein Eintrag geschrieben wird. Die älteren MyISAM-Tabellen werden nämlich während eines Schreibzugriffs komplett gesperrt.

    • » Nach den Optimierungen sollten die Tabellen wenigstens geleert werden, damit die überflüssigen Daten dann auch nicht mehr in der DB liegen bleiben. Danach sollte auch im TYPO3-Backend unter Web->Info->Indexed search->Technical Details überprüft werden, ob die Änderungen zum Erfolg geführt haben, oder ob noch unnötige Einträge vorhanden sind.

    Sollte jemand noch andere Dinge für erwähnenswert halten, dann bitte ich um Rückmeldung.

    Viel Erfolg dann noch mit der performanteren Index-Suche!

    Oliver Thiele

  • 1