Gibt es Gründe, warum FTSearch in einem Type-Ahead auf einer XPage keine geeignete Alternative zu DBColumn ist, wenn Sie versuchen, die Leistung zu verbessern?

Ich habe in meinem aktuellen Projekt eine allgemeine Anforderung, eine vorhandene XPage-Anwendung schneller zu machen. Eine Sache, die wir uns angeschaut haben, war, wie man einige langsamere Typ-Ahead-Felder beschleunigt, und eine Lösung dafür, die schnell zu sein scheint, ist die Implementierung mit FTSearch und nicht mit der DBColumn, die wir ursprünglich hatten. Ich möchte mich beraten lassen, ob dies ein OK-Ansatz ist oder ob es Vorschläge gibt, was wir anders brauchen.

Hintergrund: Während es bei der Verwendung von 8.5.3 eine Reihe von Faktoren gibt, die sich auf die Geschwindigkeit auswirken (wie Netzwerklatenz, Serverbetriebssystem, verfügbarer Serverspeicher usw.), haben wir die Anwendung im Allgemeinen so weit wie möglich optimiert, indem wir die IBM Toolkit, um Problembereiche zu finden und auch die Funktionen zu verwenden, die IBM in 8.5.3 dazu beigetragen hat (z. B. Teilausführung, Verwendung der optimierten JS- und CSS-Option usw.). Leider sind wir für ein paar Monate mit dem Server auf einem 32-Bit-Windows-Betriebssystem mit 3.5 Gb Ram stecken.

Eines der langsamsten Elemente, auf die reagiert werden soll, sind bestimmte Schnellzugriffe, die auf eine große Anzahl von Dokumenten verweisen. Der schlechteste Durchschnitt liegt bei 5 bis 6 Sekunden, bevor die vorgeschlagene Liste für ein Feld mit aktivierter Eingabehilfe angezeigt wird. Es verwendet SSJS, um eine Java-Klasse aufzurufen, um einen dbcolumn-Aufruf auszuführen (mit Ferry Kranenburgs XPages Snippet ), um eine eindeutige Liste aus einer Ansicht zu erhalten. Anschließend wird in SSJS eine Schleife durch das Array durchlaufen, um zu prüfen, ob jeder Eintrag den Suchschlüsselwert und enthält Wenn es gefunden wird, fügt es ein Highlight (fett) HTML-Tag um den Suchtext in dem Wort hinzu und gibt dann die formatierte Liste zurück an den Browser. Ich habe eine print-Anweisung hinzugefügt, um die verstrichene Zeit auszugeben, die benötigt wird, um den Code auszuführen, und im Durchschnitt heute auf unserem Entwicklungsserver sind es etwa 3250 ms.

Ich habe ein paar Dinge ausprobiert, um zu sehen, wie wir diesen Prozess beschleunigen können:

1. Es wurde eine Java-Klasse hinzugefügt, um die gesamte Verarbeitung durchzuführen (also nicht mit SSJS). Dies hat nur durchschnittlich 100ms gespeichert.

2. Unter Verwendung einer view-scope Managed Bean habe ich die eindeutige Lookup-Liste in den Speicher geladen, wenn die Seite geladen wird. Dies führt zu einer sehr schnellen Eingabeaufforderung (16 ms), aber ich vermute, dass dies ein sehr schlechter Weg ist, dies mit einem großen Datensatz zu tun - und könnte den allgemeinen Server beeinflussen, wenn mehrere Benutzer darauf zugreifen die Anwendung. Ich habe versucht, Informationen darüber zu finden, was als großes Objekt betrachtet werden würde, konnte aber keine Anleitung oder Empfehlung finden, wie viel zu viel im Speicher zu speichern ist (ich habe JSF- und XPage-Sites durchsucht). Hat jemand irgendwelche Vorschläge dazu?

3. Immer noch in einer Java-Klasse - anstatt dblookup auszuführen, um die 'Liste' aller zu durchsuchenden Werte zu erhalten, lasse ich den Code eine FT-Suche ausführen, um die doc-Sammlung zu erhalten den Feldwert, den ich möchte, und füge diese einem 'SortedSet' hinzu (das automatisch keine Duplikate zulässt), dann wiederhole den sortierten Satz, um die fetten Tags um den Suchbegriff herum einzufügen, und gebe diesen an den Browser zurück. Das dauert durchschnittlich 100ms - das ist großartig und kaum wahrnehmbar. Gibt es Nachteile bei diesem Ansatz - oder Gründe, warum ich es nicht so machen sollte?

Vielen Dank für Feedback oder Ratschläge zu diesem Thema. Pam.

Update 14. August 2013: Ich versuchte einen anderen Ansatz (inspiriert von der IBM / Tony McGuckin Insights-Anwendung auf OpenNtf ) als die Unternehmenssuche, die verwaltete Beans verwendet und viele Daten schnell verarbeitet.

4. Obwohl die Insights-Anwendung sich auf Daten bezieht, die über mehrere Datenbanken verteilt sind, ist das Prinzip für die Typvorgabe ähnlich. Ich konnte eine Ansicht mit getAllEntriesByKey jedoch nicht verwenden, da ich auch innerhalb des Textes nach einer Zeichenfolge suchen musste, nicht nur am Anfang des Eintrags. Ich habe versucht, eine ViewEntryCollection basierend auf einer Ansicht FTSearch zu erstellen, aber da wir viele doppelte Namen in der Spalte haben, gab dies nicht die eindeutige Liste, die ich wollte. Ich habe dann versucht, einen NotesViewNavigator in einer kategorisierten Ansicht zu verwenden und diese zu durchlaufen. Dies erzeugte die einzigartige Liste, die ich brauchte, aber es stellte sich heraus, dass sie langsamer war als alle anderen oben genannten Methoden. (Ich habe diese ViewNavigator-Leistungstipps implementiert.