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.

Entgegen dem Stand vor wenigen Jahren ist Google Maps sehr belastbar und stabil geworden. Um die Möglichkeiten und Grenzen für den Einsatz etwas besser einschätzbar zu machen, habe ich einige Tests gemacht.

Zur Erzeugung von vielen Punkten auf einer Map verwendete ich dazu einen “Random Point Generator” (http://www.geomidpoint.com/random/). Hiermit kann man große Mengen an Punkten erzeugen und in Google Maps darstellen. Allerdings wird hier kein HTML-Code für die Beschreibung des Punktes mitgeliefert. Getestet habe ich auf einem recht schnellen Desktop Rechner mit aktuellen Browsern, auf einem aktuellen mittelmäßig schnellem Notebook und einem alten Rechner mit dem Internet Explorer 6.

Ergebnisse / Performanceauswertung:
Firefox 3, Internet Explorer 7, Safari 3, Opera 9.6 auf dem schnellen Rechner und dem Laptop:

• bei ca. 200 Punkten noch akzeptabel performant
• bei ca. 500 Punkten wird die Karte deutlich langsamer (Aufbau ca. 5-6 Sek.)
• bis zu 2000 Punkte haben funktioniert, aber der Aufbau ist dann zu langsam für einen Einsatz auf einer Website (1500 Punkte knapp 20 Sek., 2000 Punkte knapp 40 Sek.)

Internet Explorer 6 auf dem älteren Rechner:

• ab ca. 25 Punkten wird der Seitenaufbau langsamer
• ab ca. 50 Punkten ist der Seitenaufbau zu langsam für eine sinnvolle Nutzung, Aktionen in der Karte sind sehr hakelig (zoomen, bewegen)
• bei ca. 150 Punkten wird sogar noch eine Karte aufgebaut, die Wartezeit im Browser suggeriert aber einen Absturz

HTML Beschreibung:

• Eine einfache HTML-Beschreibung erzeugt vor allem HTML-Markup in der Seite, was zum langsameren Laden führen kann.
• Wird das Markup einfach gehalten, gibt es beim Aufbau im Frontend zwar ein kleines Flackern (bei 250 Punkten), aber die Aufbauzeit scheint sich nicht wesentlich zu verzögern.

Fazit:
Wenn man mit bis zu max. 50 Punkten arbeitet, gibt es keine Probleme. Möchte man mehr Punkte verwenden, sollten ältere Browser (IE6) ausgeklammert werden, da die Nutzung dort dann nicht mehr sinnvoll möglich ist. Und auch dann mehr als 250 Punkte sind kritisch zu sehen. Es funktionierten zwar auch mehr Punkte halbwegs performant, aber hier habe ich auch schnelle aktuelle Rechner verwendet.