Immer wieder sprechen wir mit Kunden, die sehr alte Notes-Anwendungen im Einsatz haben. Das sind oft Anwendungen, die vor vielen Jahren entwickelt wurden und mit der Zeit immer mal wieder neue Funktionen bekamen, ab und zu "geflickt" wurden und wo vieles nach dem Motto "Never change a running system" verläuft. Das ist insofern verständlich, als dass diese Anwendungen einen wichtigen Platz im Unternehmen oder der Abteilung einnehmen, die Anwender sich über Jahre an die Arbeitsabläufe gewöhnt haben oder gesetzliche Vorgaben Eingriffe erfordern.

Das allein ist kein Problem: Notes/Domino ist ein robustes System. Auch wenn einige neue Features im Laufe der Jahre dazugekommen sind (und ab Notes-Version 10 wieder vermehrt hinzukommen werden), so tut einmal geschriebener Code seinen Dienst. Es hat sich nicht grundsätzlich etwas an der Art und Weise geändert, wie man Notes-Anwendungen programmiert.

Problematisch wird es, wenn die Neuerungen im Programm zulasten der Performance gehen. Kein Anwender hat Lust, ewig auf das Öffnen einer Ansicht oder eines Dokuments zu warten, nur weil in der neuesten Version deutlich mehr Daten gespeichert werden sollen als vorher. Da hilft es auch nicht, wenn die Arbeitsabläufe wie im Schlaf beherrscht werden. In diesem Fall kann es sich lohnen, statt die Anwendung komplett neu zu schreiben, an gewissen Performance-Stellschrauben zu drehen oder punktuell Programmcode zu optimieren.

In einer früheren Serie von Blog-Artikeln haben wir bereits vorgestellt, wie Teile einer Anwendung oder eines Workflows als Web-Anwendung von überall und zu jeder Zeit erreichbar sind. So kann man sich losgelöst von Abläufen innerhalb von Notes an den gewünschten Stellen einklinken und maßgeschneidert sowohl performant als auch mit flexibler und ansehnlicher Weboberfläche das Problem bearbeiten.

Doch auch wenn eine Notes-interne Lösung gewünscht ist, lässt sich häufig etwas Geschwindigkeit aus dem Programm herauskitzeln. Dabei ist es sowohl möglich, den Programmcode effizienter zu gestalten als auch server-/datenbankseitig bessere administrative Voraussetzungen zu schaffen.

An dieser Stelle wollen wir genauer auf Möglichkeiten für Entwickler eingehen.

Vorweg sei erwähnt, dass eine sinnvolle Konzeption der Anwendung zu Beginn eines Projektes das A und O ist. Hier hat man noch alle Freiheiten, Masken, Ansichten und Abhängigkeiten so zu definieren, wie es für den jeweiligen Anwendungsfall optimal ist. Dass es bei bestehenden Anwendungen oft schwierig oder nicht sinnvoll ist, das Herzstück umzuprogrammieren, macht diesen Punkt einerseits umso wichtiger, lenkt andererseits den Fokus auf die verbleibenden, zahlreichen Möglichkeiten.

Die beiden einflussreichsten Stellschrauben sind die Anzahl der Dokumente und die Anzahl/Größe der Ansichten.

Lädt eine Ansicht zu langsam, lohnt es sich, die verwendeten Formeln genauer anzuschauen. Die wichtigste ist dabei die Ansichtsauswahlformel. Welche Dokumente werden überhaupt angezeigt? Ist die Formel performant geschrieben? Ist es möglich auf gewisse Dokumente (wie zum Beispiel Antwortdokumente oder veraltete Dokumente) in der Ansicht zu verzichten und sie stattdessen auf eine andere Art zugänglich zu machen? Dabei muss man auch im Hinterkopf behalten, dass eine Auswahlformel auf eine sehr große Menge an Dokumenten zutreffen kann, der einzelne Anwender möglicherweise jedoch aufgrund von Leser- und Bearbeiterfeldern nur einen Bruchteil der Dokumente zu Gesicht bekommt, während die überflüssigen Dokumente dennoch zumindest im Hintergrund für einen Performanceverlust sorgen. Oft sollte man lieber kleinere, spezialisiertere Ansichten bauen, statt wenige aufgeblähte Universalansichten. Das Motto lautet: Berechne so viel wie nötig, aber so wenig wie möglich.

Dies gilt ebenso für die Spaltenformeln. Anstatt in einer Ansicht mehrere Werte in einer Spalte zu verketten (bspw. Vorname und Nachname mitsamt Geburtsdatum und -ort) kann man diese Berechnung in ein weiteres Feld des zugehörigen Dokuments auslagern, welches immer nur genau dann neu berechnet wird, wenn sich eines der Bezugsfelder ändert. Insbesondere dann, wenn man diese Information in mehreren Ansichten benötigt, spart es nicht nur Berechnungen, sondern sorgt automatisch für ein konsistenteres Datenbild und weniger Wartungsaufwand bei Codeänderungen. Auch Icon- und Kategorie-Spalten verlangsamen den Ansichtsaufbau - hier sollte man besonders zwischen fachlichem Nutzen und gewünschter Geschwindigkeit abwägen. Natürlich hat auch die Anzahl der Spalten einen wichtigen Einfluss. Man sollte immer direkt mit dem Kunden abstimmen, ob die Nutzer alle vorgehaltenen Informationen in den Ansichten wirklich benötigen. Schließlich können weniger angezeigte Informationen eine Ansicht für den Nutzer auch übersichtlicher machen, wenn diese zuvor überfüllt war.

Eine auf den ersten Blick unscheinbare Eigenschaft, die jedoch direkt für eine Vervielfachung des Ansichtsindex sorgen kann, ist die Sortierbarkeit von Spalten. Dies liegt daran, dass für jede mögliche Sortierung einer Ansicht ein separater Index vorhanden sein muss, damit bei Änderung der Sortierung schnell die neue Reihenfolge der Dokumente angezeigt werden kann. Aber auch hier gibt es verschiedene Wege, für Entlastung zu sorgen, wenn die vorhandenen Sortierungen fachlich notwendig sind. Einerseits sollte man bei Sortierungen "in beide Richtungen" (sowohl aufsteigend als auch absteigend) abstimmen, ob vielleicht eine der beiden Optionen genügt und die andere nur selten genutzt wird. Auch kann es vorkommen, dass die gewünschte Sortierung so oder so ähnlich schon in einer anderen Ansicht vorhanden ist. In diesem Fall kann man besser einstellen, dass bei Klick auf die Spaltenüberschrift zur anderen Ansicht gewechselt wird. Ist eine Sortierbarkeit zwingend, ohne jedoch häufig genutzt zu werden, kann man die Indexerstellung am besten erst bei der ersten Nutzung durchführen sowie den Index verwerfen, wenn die Ansicht einige Tage nicht genutzt wird.

Auf die Gesamtzahl der Dokumente in einer Datenbank hat man als Entwickler bei einer bestehenden Anwendung nur schwerlich Einfluss. Sollte es jedoch noch keinen Archivierungsmechanismus geben, so wäre dies der erste Schritt, der zu gehen ist, um die Anzahl zu verringern. Außerdem erzeugen Deletion Stubs bei einigen Operationen den gleichen Aufwand wie normale Dokumente. Hat man also kurze Replizierintervalle zwischen den Servern und werden auch die lokalen Repliken regelmäßig aktualisiert, kann man ruhigen Gewissens das Löschintervall für Deletion Stubs verkürzen.

Beim Aufbau von Masken sind es oft Lookup-Formeln, welche das Laden von Dokumenten verlangsamen. Gängige Techniken, Lookups zu beschleunigen sind einerseits die Caching-Parameter sinnvoll zu verwenden (z. B. den Lookup-Cache nur beim Öffnen eines Dokuments zu erneuern), andererseits die Anzahl der Lookups zu verringern, indem man mehrere in einem kombiniert. Besonders große Masken mit vielen Feldern und Tabellen lassen sich zudem optimieren, indem man Mehrfachwertfelder statt mehrerer Einzelfelder nutzt, die Berechnung häufig genutzter Versteckformeln auslagert und für das Frontend irrelevante Felder ohne Summary Flag speichert.

Dies soll als Einstieg zu den Themen Ansichten, Dokumente und Masken genügen. Natürlich gibt es noch eine Menge weiterer Möglichkeiten, diese Punkte zu optimieren. Wenn man die oben genannten Punkte abarbeitet, sollte man jedoch schon sichtbare Fortschritte erzielt haben.

Die Besprechung einiger weitere Themen, insbesondere Code-Optimierung, werden in einem weiteren Blog-Artikel folgen.

Wir unterstützen Sie natürlich gerne, Ihre Anwendungen auf höchste Performance zu optimieren. Sprechen Sie uns hierzu einfach unter +49 4307 900 408 oder per Mail an kontakt@assono.de an.