Kategorie- Twistie: Dauert >20 Sekunden zum Expand / Collapse...

[Tode]

Ich habe eine Datenbank mit 200.000 Dokumenten in einer Kategorisierten Ansicht.
Es gibt keine Leserfelder in den Dokumenten.

Wenn ich die xPage Standardmässig expandiert ist, dann dauert das Anklicken der Twisties wenige Sekunden.
Setze ich aber den expandLevel auf 1, so dass alles komprimiert ist, dann dauert das öffnen eines einzelnen Twisties (und auch das schliessen) >20 Sekunden.

Die Erklärung ist recht einfach: Wenn alles expandiert ist, dann muss die xPage- Engine im besten Fall bis zum 10. Dokument, im schlechtesten bis zum 28. Dokument gehen (bei 30 angezeigten Zeilen und jeweils 2 Kategorien), um festzustellen -> Seite voll -> Kann aufhören...

Ist alles collapsed, dann passen die wenigen Kategorien (leider) auf eine Seite. Das heisst, die Engine muss alle 200.000 Dokumente durchgehen, um festzustellen, dass es nix weiter anzuzeigen gibt.

Jetzt meine Frage: Kann ich das "Performance- Tunen" oder muss ich mir eine andere Darstellungsweise für die xPage überlegen und weggehen von den Kategorien (z.B. eine Art "Ordnernavigation" links mit den Kategorien aufbauen, und dann einen ViewFilter setzen...)?

Ich musste schon die XSP.submitLatency hochsetzen, damit das anklicken des Twisties überhaupt durchgeführt wird (weil >6 Sekunden Standard- Timeout)

[flaite]

Große Resultsets sind sicher eines der letzten größeren Abenteuer von Enterprise Computing.

Geht mir mit meinem RichFaces/JSF2 - EJB-like - JPA2 stack genauso.

Schon mal ein network-sniffer dazwischengehängt, um zu schauen, was da für eine Ajax-Kommunikation abläuft?
Dies würd auch bedeuten, dass bei einer schlechteren Leitung - und dein Browser liegt vermutlich auf dem selben Rechner wie der Server - alles noch viel schlimmer ist.

[Tode]

So tief bin ich noch gar nicht gegangen. Wie gesagt bin ich mir (aufgrund meiner Erfahrung mit Ansichten in Lotus Notes im allgemeinen) relativ sicher, dass es (vereinfacht) so abläuft:

- Hole nächstes Dokument in Ansicht
- Prüfe, ob dieses Dokument eine Zeile zur Ansicht hinzufügt (entweder indem es eine neue sichtbare Kategorie begründet, oder selbst direkt angezeigt wird, weil die Kategorie aufgeklappt ist)
- Addiere die Anzahl der neu hinzugekommenen Zeilen zu der Anzahl der bereits zum rendern gemerkten Zeilen
- Wenn Anzahl Zeilen >= Maximale Anzahl -> Beende Loop und rendere
- Ansonsten beginne oben...

Wie gesagt: Bei 200.000 Dokumenten, die 10 Kategorien begründen und einer Anzeige von 30 Zeilen heisst das: Die xPage muss alle Dokumente prüfen um dann am Ende festzustellen: Seite ist nicht voll... Anzeigen.

Genau diese Begründung macht die Anzeige von Ansichten mit Kategorien und Leser- berechtigten Dokumenten bei einer grossen Anzahl Dokumenten so unendlich langsam.

Und ich KÖNNTE mir vorstellen, dass die xPage eben genauso vorgeht wie der Client (da konnte man ja bestehenden Code weiterverwenden)...

Die Frage ist: Liege ich mit dieser Vermutung richtig? Und das nachzuprüfen dürfte per Sniffer nicht möglich sein, weil ich dort nur den Request sehen würde, die ganze Verarbeitung findet auf dem Server statt... und dann sehe ich im Sniffer wieder die Antwort. Ich bin mir ziemlich sicher, dass in den 30 Sekunden dazwischen Funkstille herrscht, werde das aber sicherheitshalber prüfen.

EDIT: Habs überprüft... ist wie ich gedacht hatte: In den 20sec. Gedenkzeit herrscht Funkstille...

[flaite]

In den 20sec. Gedenkzeit herrscht Funkstille...

Danke. Hätt ich nicht gedacht. Und gut, dass du gemessen hast.

Wir hatten damals in 4.6 mal einen in einem LotusScript Agenten programmierten Navigator. Klickte der Kunde auf eine Kategorie, dauerte es ohne Scherz 8 bis 15 Sekunden, bis die Unterkategorien erschienen. Nach dem Tage der Auslieferung fuhr der dafür verantwortliche Entwickler in den Urlaub und verabschiedete sich von dem Kunden - Einkauf von Daimler - mit den Worten: Dass das nun so lange dauert, ist ein cache-Problem. Das ist im Web so. Am Montag ist das viel schneller". Am Montag hatte ich den Kunden an der Leitung... Ich war zu dem Zeitpunkt 5 Monate Domino Anwendungsentwickler.
 
Ich hab das dann unter viel Ermutigung vom verzweifelten Kunden und viel Druck von meinem damaligen eher betriebswirtschaftlich orientierten Abteilungsleiter das ganze mit Formelsprache, Domino URL Syntax und JavaScript rein Clientseitig programmiert. Gibt in Formelsprache, was das in Ansichtspalten die Kategorisierung des Dokuments in einer 1.1.1... 1.1.2 ... etc. als special text ausgibt. Das läßt sich zwar nicht mit Formelsprache aber mit dynamisch generierten JavaScript verarbeiten. Darauf beruhte das damals. Waren aber kleine Resultsets. Damit liefen wir völlig aus dem Budget, ansonsten hätte das aber auch vor Gericht enden können. Ich war damals auch gehaltsmässig echt günstig.  


Lange Rede, kurzer Sinn: Du mußt irgendwie versuchen die Menge der übertragenen Dokumente beschränken. start=1&count=n, aber das verträgt sich afaik nicht wirklich gut mit Domino Kategorien.
Vielleicht kategorisierte Ansichten und dann jeweils nur 1 Kategorie anzeigen.

...in JSF Welt glauben auch viele, dass es ein "echtes paging" als Komponente dabei wäre. Also was, das gegen Oracle in etwa so macht:
select *
  from ( select a.*, rownum rnum
           from ( YOUR_QUERY_GOES_HERE -- including the order by ) a
          where rownum <= MAX_ROWS )
 where rnum >= MIN_ROWS

Das kanns natürlich gar nicht geben. Muss man selber implementieren.
Die bestehenden Komponenten liefern out of the box nur, dass von einem großen geladenen Resultset alles im Managed Bean gehalten wird und die Client Komponente sich immer nur 1 Teil
in den Browser zieht. Aber bei großen Resultset dauert natürlich schon das holen der Einträge von der Datenbank ins Managed Bean viel zuviel Zeit.

[Sven Hasselbach]

Die Frage ist: Liege ich mit dieser Vermutung richtig?

Ja, die Zeilen der Ansicht werden durchgegangen. Das zweite Problem sind Pager, die müssen ja ebenfalls durchgerattert werden.
Setzt mal die angezeigten Zeilen des ViewPanels runter und schmeiss den Pager raus...

[Tode]

Der Pager hat interessanterweise keinen direkten Einfluss auf die Ladegschwindigkeit...
Das heruntersetzen auf 5 sichtbare Zeilen erhöht die Geschwindigkeit ganz signifikant, aber ist natürlich auch nicht der Weisheit letzter Schluss... Ich denke ich werde mit View- Filter arbeiten und eine Kategorie- Naviagation links in Form einer "Ordnernavigation" realisieren. Das geht dann mit einem gecachten DBLookup (recht performant) und der View- Filter ist hoffentlich schneller als die Category- Control...