Tomorrow Comes Today

Für Google Maps können ja problemlos eigene Marker gesetzt werden. Hier werden natürlich PNGs bevorzugt, da diese saubere Kanten behalten können. Im Internet Explorer 6 ist das etwas problematisch. Hier ist es auch schwer oder gar nicht möglich, ein PNG einzubinden (bitte Hinweise für bessere Lösungen an mich). Eine sehr saubere Lösung ist, im IE6 einfach die Standard Marker von Google zu verwenden. Das geht einfach über eine Javascript Weiche zu realisieren.

if(vIE()!=6) icon.image = “../typo3conf/ext/projecttheme/res/css/img/gMaps_marker.png”; 

function vIE(){
return (navigator.appName==’Microsoft Internet Explorer’)?parseFloat((new RegExp(”MSIE ([0-9]{1,}[.0-9]{0,})”)).exec(navigator.userAgent)[1]):-1;
}

Das T3BLOG ist eine recht umfangreiche Blog-Extension. Sie hat einfachere Eingabemodule im Backend, verschiedenste Frontendanzeigen und vor allem: Sie unterstützt Features wie Blogroll, Trackback, Ping usw. Allerdings arbeitet die Extension mit vollkommen eigenen Tabellen und Modulen und somit leider recht weit von den Kernstrukturen von TYPO3 entfernt. Dadurch ist auch die Codemenge sehr umfangreich, wobei viele Strukturen und Funktionen eigentlich schon vorhanden sind. Der Umfang und die Funktionalität sieht auf den ersten Blick aufgeräumter als bei TIMTAB aus, allerdings ist das Kernkonzept ähnlich wie bei tt_news nicht das, was ich mir wünschen würde.

Google Maps bietet für den User zusätzliche Tools. Eines ist bspw. ein Logitude/Latitude-Marker, ein anderes ein Logitude/Latitude-Tooltip. Besonders geeignet sind solche Tools für Webredakteure, die im Backend von TYPO3 oder Drupal direkt die Geodaten eingeben müssen - welche aber natürlich kein Normalsterblicher kennt oder aus dem Stehgreif heraus findet.

Die TYPO3 Extension Tag Pack bietet eine flexible Möglichkeit TYPO3 Inhalte beliebiger Tabellen zu taggen. Gerade die Unabhängigkeit der Tabellen macht sie attraktiv. In der Standardkonfoguration sind zunächst “pages” und “tt_content” aktiviert. Das Tagging erfolgt über die einfache Eingabe in ein AJAX-Feld. Ist das Tag noch nicht vorhanden, wird es einfach angelegt. Sind passende Tags zur Eingabe vorhanden, erscheint eine Live Search unter der Box. Von Drupal und anderen Blog Tools ist man sowas gewöhnt - für TYPO3 ist das eine kleine Revolution und lässt das Tagging vielleicht endlich in die TYPO3-Welt einziehen. Die Tags können über das Listenmodul verwaltet werden - oder über ein sehr eigenartiges Backend-Modul. Die Extension brigt noch eine Tagclound und eine Liste von Einträgen mit. Also im Grunde erstmal das, was man braucht. Toll ist, dass sich durch die Unabhängigkeit von den Tabellen die eigenen Konzepte - wie z.B. semantische Seitentypen als Grundentitäten - einfach durch das Tagging ergänzen lassen.

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
}
}

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.