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

Sollten die Probleme also die Einsetzbarkeit nicht  überwiegen, kann man sich auf viele spezielle Controls freuen. Besonders bemerkenswert finde ich die Spreadsheet Komponente, mit Rendering von Diagrammen, Formeln usw. Entsprechende Komponenten im Open Source Bereich sind nicht allzu weit verbreitet. Ebenfalls dehr schön und umfangreich ist die Kalender Komponente, welche irgendwie durch den Minimalismus und das hellblau an Google erinnert.

Ich bin gespannt, wo wir die Komponenten mal einsetzen werden.

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).

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.

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!

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.

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.

• Für Teaserlisten - welche wir gewöhnlich mit TYPO3 Menüs erstellen - verwenden wir je nach Anforderung häufig das HMENU mit special = list, worin wir dann eine UID-Listen von Seiten übergeben. Das HMENU löst bei special = list allerdings nicht die Workspace Versionen bzw. das Version Overlay auf. Das führt dazu, dass man solche Teaserlisten im Draft Workspace zwar anlegen kann, aber die Vorschau je nach Versionszustand der Zielseite falsche Teaser anzeigt. Wir haben die Stelle per XCLASS angepasst. (TYPO3 Bugtracker 0010901: HMENU with special = list does not use versionOL)
• Ebenfalls für solche Teaserlisten aber z.B. auch für andere Zwecke nutzen wir zusätzliche Bild-Attribute in den Seiteneigenschaften (genau wie das Feld wie Media). Leider werden die DAM Referenzen zur Tabelle pages nicht entsprechend ihrer Workspace Versionen aufgelöst und auch hier kommt es folglich zu Problemen. (TYPO3 Bugtracker 0010902: dam references of page attributes do not work with workspaces)
• Bei der Verwendung von Bildern und Dateien im Draft Workspace kommt es zu dem Phänomen, dass die Seitenvorschau nur bereits Live publizierte Bilder oder Dateien anzeigt. Laut TYPO3 Bugtracker soll das Problem bereits behoben sein, aber bei uns treten die Probleme noch auf. Neuigkeiten folgen! (TYPO3 Bugtracker 0007344: DAM does not preview correct files in workspaces)

Evtl. sind die Workspace nicht häufig bei größeren Websites im Produktivbetrieb - jedenfalls scheint es noch einige “Kinderkrankheiten” zu geben.