Tomorrow Comes Today

Ein Hoch auf die Browservielfalt:Es gibt eine neue Safari Version 4. Die Highlights: CSS 3 Webschriften, SVG-Unterstützung, Nitro JavaScript-Engine (soll schnell sein), spannende Entwicklerwerkzeuge u.v.m.

Bleibt nur zu hoffen, dass die Safarinutzer sich weiterhin ähnlich wie die Operanutzer verhalten und recht zügig ihre Versionen aktualisieren und die Vielfalt nicht noch steigt. Mein Appell: Seid Vorbilder für die MS Community und nutz eine und nicht drei Browserversionen gleichzeitig. Da man sich darauf aber nicht verlassen kann, werden Tolls wie Xenocode immer wichtiger (Danke an MH).

Kleine Erkenntnis: Die Index-Einstellungen im Setup müssen in config UNTERHALB von page stehen! Und natürlich NICHT in page einer Druckansicht oder einer Feed-Ausgabe. Ansonsten landen diese Ansichten alle im Suchindex.
page {
config {
index_enable = 1
index_externals = 1
}
}

Zur Doku von PHP-Code ist die klassische phpDoc-Dokumentation am eingängigsten. Per phpDocumentor kann aus dieser Dokumentation im Code eine HTML-Doku erstellt werden. Hier gibt es eine einfache Anleitung, wie man das ganze in Eclipse verwendbar macht.

Wie schön ist dieses Bild und wie hoffnungsvoll sind alle Entwickler bei dieser vidion geworden … doch noch ist der IE6 da und noch wird es wohl eine Weile so bleiben.

Nun ist die mitunter schlechte Performance der Indexed Search nicht mehr nur ein Verdacht, sondern bewiesene Tatsache. Um für sehr umfangreiche TYPO3-Seiten noch eine gute Performance einer Volltextsuche gewährleiten zu können, mussten wir zum einen Fakten schaffen, um die Probleme einschätzen zu können. Und da die Bedenken auf der Hand liegen, haben wir gleich die PHP Lucene auf Basis der Powersearch Extensions in den Test mit einbezogen.

Testaufbau

• Ein neu installiertes TYPO3 System in der Version 4.2.6.
• Installation der Indexed Search in der Standardkonfiguration.
• Installation der Lucene über die verfügbaren Powersearch-Extensions in der Standard­konfiguration.
• Erzeugung von großen Mengen an Dummy Inhalten:
  • Der Inhalt wurde wir folgt erstellt: Als Basis dient eine Wörterliste mit deutschsprachigen Wörtern (ca. 150.000), welche wir um alle Wörter welche weniger als vier Buchstaben haben, gekürzt haben. Diese Liste wird sequentiell durchgearbeitet und für jedes Wort eine Google Anfrage gestellt. Als zu verwendender Ergebnistext werden alle Suchergebnisse der ersten Seite verwendet und von HTML-Code befreit (strip_tags).
  • Mit diesem Inhalt wird ein Seitenbaum erstellt. Eine Seite enthält immer ein Inhaltelement mit dem o. g. Text. Es werden 22 Seiten mit je 22×22 Unterseiten erstellt.
  • So entstehen ca. 11.000 Inhaltseiten mit sehr unterschiedlichem Textinhalt.
• Für beide Suchen wird die Indizierung gestartet. Bei der Indexed Search per TYPO3 Crawler über die Seiten, bei der Power Search per Cron.
• Letztlich können Suchanfragen einfacher Begriffe (immer nur ein Begriff) über beide Suchmasken gestellt werden. Die Messung erfolgt über die Requestzeit per Firefox Plugin. Diese umfasst zwar nicht nur die Suchanfrage und ist somit nicht unbedingt exakt, aber letztlich ist für die Nutzung zum einen die Gesamtperformance interessant und zum anderen ist nur ein sehr deutlicher Unterschied eine ausreichende Rechtfertigung für den Austausch der Indexed Search gegen Lucene.

Ergebnis

Der Unterschied in der Suchgeschwindigkeit bei einfachen Begriffen und ca. 11.000 Seiten mit unterschiedlichen Inhalten ist enorm. Die Lucene basierte Suche bleibt nutzbar, die Indexed Search braucht ab 40 Sekunden aufwärts (gerne auch mal 1 ½ Minuten) für eine Anfrage - wird allerdings bei wiederholten Anfragen aufgrund des mySQL Query Cache schneller - doch dieser bringt bei Volltextsuchen praktisch nicht viel.

Fazit
Lucene ist in der Suchperformance bei großen Mengen an Inhalte grundsätzlich besser aufgestellt, da sie ein spezielles Indizierungskonzept verwendet, welches stark skalierbar ist. Die Indexed Search ist in Ihrer Performance durch die wortbasierte Indizierung, die SQL-Query-Logik und die Datenbankperformance eingeschränkt und nur bedingt skalierbar.

Ein Hoch auf Lucene!

Zum letzten Artkel wurden mir als alternative Lösungsmöglichkeit mehrmals die Geo Cubes (www.geocubes.com) von skilldeal empfohlen. Das besondere an den Cubes ist vor allem das Clustering, d.h. hier werden Massen an Geo-Punkte je nach Zoomstufe zu Clustern zusammengefasst und dem User angezeigt, dass dort weitere Einträge beim näheren Heranzoomen zu sehen sind. Klasse! Ein Beispiel ist direkt auf der o.g. Website zu sehen.

Und noch ein Nachtrag:  Den auch die Google Maps API selbst bietet weitere Optimierungsmöglichkeiten. Dieser kann man sagen, dass z.B. nur Punkte welche im aktuellen Viewport auch sinchtbar sind, gerendert werden. Dies sollte die kritischen Lastgrenzen nocheinmal deutlich entschärfen. Ein entsprechendes Proof of Concept steht noch aus - aber auch an.