Das Notes Forum
Domino 9 und frühere Versionen => ND6: Administration & Userprobleme => Thema gestartet von: BANXX am 14.03.05 - 12:21:28
-
Ich habe seit einiger Zeit auf meinem WebServer arge Performanceprobleme - es dauert bis zu 30 Sekunden, bis die erste Seite aufgebaut wird, egal ob das eine HTML-Datei (3kb) ist oder eine Datenbank, DWA oder sonstwas. Es spielt auch keine Rolle, ob ich über das Internet, Intranet oder komplett lokal (localhost) auf den Server zugreife. Jeder Seitenaufruf ist tierisch langsam.
Leider kann ich den Zeitpunkt, seit wann die Performanceprobleme aufgetreten sind, nicht genau definieren... Ich kann also nicht 100%ig sagen, ob es am FP1 liegt, oder an der Umstellung von Windows 2000 auf 2003 oder an der Installation der Antivirenlösung (Deaktivieren bringt keine Änderung....)
Der Windows Taskmanager bringt auch keinen Aufschluß darüber, was so Probleme macht, dem Rechner scheint es gut zu gehen.
Hat jemand noch ne Idee oder kann ähnliches beobachten ?? Ich versuche gerade, einen möglichst großen Kreis an potentiellen Beobachtern zusammen zu tragen...
-
Setzt denn keiner Domino 6.5.3FP1 mit http auf Windows 2003 ein ???
-
Z.Z nur unter 2000 8)
aber keine Probleme bisher, zumindest nicht mit der HTTP Task ::)
-
Hallo!
Deine Informationen sind etwas dürftig. Zuerst mal würde ich überprüfen, ob im Taskmanager irgendein Task 100% CPU Last hat. Dann würde mich interessieren, wie sich der Server beim Zugriff über den Notes Client verhält. Hast du eventuell die DNS Suche beim HTTP Task im Serverdokument aktiviert und ein Reverse Lookup funktioniert nicht?
Grüße
Ralf
-
Mich nervt das echt, wenn Leute eine Frage posten und man dann antwortet und es erfolgt keine Reaktion mehr auf die Antwort. Falls es was gebracht hat wäre ein kurzes Danke angebracht, falls nicht würde ich mich auch freuen.
Grüße
Ralf
-
Der letzte Eintrag in diesem Thread ist zwar schon mehr als 15 Monate alt, für mich ist das Thema aber aktuell. Ich brauche Literaturtips zum Thema
Wie man als Admin die Performance eines Domino-Webservers verbessern kann.
Also ist "Performance Considerations" zwar hilfreich, aber nicht genau das, was ich brauche. Ausserdem kenne ich es ja schon, wie ihr seht. Ansonsten habe ich aber leider - abgesehen vom Redbook "Domino Tuning Parameters in notes.ini" - nix Brauchbares gefunden. Weder hier im Forum, noch auf notes.net....
-
Interessant wäre jetzt aber ob du die selben Probleme wie der Ursprungsposter hast. (Antwortzeiten von über einer halben Minute) oder ob du einfach nur bessere Performance haben willst?
Falls es dir nur um Performance geht, dann wäre ein eigner Thread wohl besser, da hier OT.
Grüße
Ralf
-
Ja ich habe auch Antwortzeiten von mehr als 30 Sekunden. Allerdings denke ich, dass ich daran schon mit einer einzigen Maßnahme viel verbessern kann:
Den Wert des Server-Doku-Feldes "Number active threads" vom Defaultwert 40 auf was auch immer anheben.
Aber selbst hier wären (schrifliche) Erfahrungswerte fein. A la unter welchen Rahmenbedingungen waren welche Werte bei anderen sinnvoll. Spart Zeit.
Der Webserver ist übrigens 6.5.4FP2. Die Version passt auch ganz gut zum Thread. Mir ist es aber natürlich egal, ob dieser Thread oder ein anderer...
-
Ist bei dir der Server unter Last, wenn das Phänomen auftritt, oder hast du das immer. Hast du den Tip mit dem Reverse Lookup schon angeschaut?
Grüße
Ralf
-
Danke für die neuerliche Rückmeldung. Einstweilen hab' ich mir noch fast nichts angesehen. Ich wurde am Freitag beauftragt, bis Ende Juli eine Lösung zu finden.
Hast du eventuell die DNS Suche beim HTTP Task im Serverdokument aktiviert
Der Wert neben dem statischen Text "DNS lookup:" im Serverdoku/Internet Protocols/Http ist Disabled Ich nehme an du hast das gemeint!?!
Die miserablen Responsezeiten stehen in direktem Zusammenhang mit der Last, sind aber wohl ebenfalls auf die Konfiguration zurückzuführen. Responsezeiten von 15 - 30 Sekunden und mehr gibt's aber nur zu Bürozeiten. Jetzt (17:05) dauert der Abruf ein- und desselben Formulars keine 3 Sekunden.
-
auf OS Seite schon mal die treiber neu installiert und die Karte auf Verdacht mal getauscht?
-
Wie siehts mit der Performance der Notes Clients aus zu der Zeit wo das Problem auftritt. Übrigens 3 sek. ist eine verdammt lange Response Zeit für eine Notes Seite. Eventuell ist das gar kein Admin Problem sondern ein Entwicklerproblem. Wir machen nicht besonders viel direkt mit Notes Http, aber eine kleine Anwendung haben wir und die macht die Seiten in sehr kurzer Zeit auf. <1 Sek.
Grüße
Ralf
-
Wie siehts mit der Performance der Notes Clients aus zu der Zeit wo das Problem auftritt.
Die ist ok - ein Netzwerkproblem haben wir also nicht.
Das Design wurde vor kurzem einer umfangreichen Überprüfung unterzogen. Da dürfte nicht mehr allzu viel zu machen sein. Ich habe ja auch geschrieben "bis zu 3 Sekunden". Schnell ist was anderes, aber die Zeit gestoppt habe ich auch nicht. Einstweilen verfolge ich diese Angelegenheit nur so nebenbei. Eigentlich wollte ich mich ja zuerst mal einlesen...
Letzteres steht auch im Hintergrund meiner Antwort auf m3's Frage:
auf OS Seite schon mal die treiber neu installiert und die Karte auf Verdacht mal getauscht?
Nein, haben ich nicht. Derartige Aktionen würde ich erst dann durchführen, wenn mir absolut nichts anderes mehr einfällt.
-
Hallo "JoJo",
um auf diesen Satz von Dir zu sprechen zu kommen:
Den Wert des Server-Doku-Feldes "Number active threads" vom Defaultwert 40 auf was auch immer anheben.
Den Wert der active worker threads zu erhöhen, muss bei Dir nicht zwangsläufig zu einer besseren HTTP Performance führen. Das wird Dir nur etwas bringen, wenn Dein Server auch tatsächlich mehr als 40 worker threads benötigt, weil die entsprechende Last an eingehenden HTTP Requests vorhanden ist. Ob Dein Server bereits dieses Limit von 40 einmal erreicht hat, sagt Dir das Ergebnis des Befehls:
sh stat Domino.Threads.Active.Peak
Gib diesen Befehl an der Serverkonsole ein, wenn Deine Performance gerade mal wieder schlecht ist. Wisse aber, dass er Dir nur den Peak-Wert der gleichzeitig verwendeten HTTP worker threads zum Zeitpunkt X, seit dem letzten Start des HTTP Tasks anzeigt.
Ist Dein Wert sehr nahe an 40 bzw. genau 40, wird eine Erhöhung des Wertes evtl. tatsächlich eine Verbesserung bringen (langsam erhöhen! Das von IBM empfohlene Maximum liegt bei 128!). Allerdings wird auch mehr Arbeitsspeicher und CPU des Servers verbraten werden.
Grüße
Daniel
-
Eventuell solltest du auch mal folgendes in Betracht ziehen. Vor allem wenn eure Zugriffe wirklich so aufwendig sind.
http://www-1.ibm.com/support/docview.wss?uid=swg21201715
Da ist nämlich genau so ein Problem beschrieben.
Grüße
Ralf
-
BTW JoJo es wäre nett, wenn du immer etwas schneller auf Antworten reagieren könntest. Es ist nämlich sonst etwas mühsam sich immer wieder in die Fragestellung hineinzudenken. Falls dich das Problem nicht mehr kümmert, oder es für dich keine Priorität hat, habe ich auch kein Problem aber dann sage es auch klar.
Grüße
Ralf
-
Genau auf dieses Feature von 6.5.5 wollte ich JoJo bringen, Ralf ;D
Allerdings wären da vorher noch einige Infos von ihm von Nutzen.
Ich habe mit der HTTPQueueMethod=2 (also im Prinzip Fallback auf die R5 Methode), bei einer sehr großen Domino Webanwendung eine Performancesteigerung von ca. 30% erreicht, bei einer optimalen Ausnutzung der Serverhardware (was für Webanwendungen unter Domino auf Windows keineswegs normal ist).
Für die richtige Methode muss man allerdings wissen, wie die Webanwendung(en) tickt/ticken.
cu
Daniel
-
Hallo Ralf und DigitDani!
Danke für den interessanten Input. Sorry schneller antworten ist zur Zeit für mich nicht d'rin. Ich arbeit im Second Level Support eines großen Rechenzentrums. Das ist ein wenig wie Fließbandarbeit. Und das Web-Server-Problem hat momentan nicht Priorität (s. o. Termin 31. 7.). Ich meld' mich dann morgen wieder und geh' auf den Rest ein. Einstweilen bin ich nur zu Folgendem gekommen:
sh ser
Elapsed time: 6 days 03:53:06
Transactions/minute: Last minute: 109; Last hour: 159; Peak: 2651
sh stat Domino.Threads.Active.Peak
Domino.Threads.Active.Peak = 7
:P
Den Wert des Server-Doku-Feldes "Number active threads" vom Defaultwert 40 auf was auch immer anheben" wird also wohl nix helfen.
-
Hi JoJo,
korrekt, da die active worker threads sowieso in ihrer Gesamtanzahl scheinbar nicht genutzt werden, wird eine Erhöhung nichts bringen. Du kannst natürlich nochmal am Ende der Woche den Peak Wert anschauen, falls Dir bekannt ist, dass in den letzten 6 Tagen die euer Server jetzt läuft, besonders wenig Mitarbeiter per Web zugegriffen haben.
Was aber nun auch noch interessant wäre zu wissen:
- Was sind das für Webanwendungen auf dem/den Dominoserver(n)? Handelt es sich nur um Mail WebAccess oder auch um andere?
- Wenn es auch andere Anwendungen sind, arbeitet ihr mit caching (z.B. über http response header in den Anwendungen oder über Web Site Rules?)
- Gibt es in den Webanwendungen häufig genutzte "Langläufer" Requests wie z.B. Downloads von größeren Dateien, die etwas länger Dauern können (z. B. > 10sek.)? Hier kann das Ändern der bereits erwähnten HTTPQueueMethod etwas bringen (6.5.5)
- Kannst Du in etwa sagen, wie viele Benutzer gleichzeitig eine/die Webanwendung(en) verwenden? (falls ihr Session Authentication aktiviert habt, könnte hier ein Blick auf die aktiven Internet Benutzer zur Stoßzeit Aufschluss bringen)
cu
Daniel
-
Hallo Jojo,
wenn der Peak bei 7 liegt, würde ich die Threadanzahl auf 10 oder max. 15 runtersetzen. Es ist nämlich nicht so, dass mehr Threads mehr Performance bringen. In irgendeinem Redbook der IBM stand auch mal, dass die zur Verfügung gestellten Threads dem genutzten Peak in etwa entsprechen sollten. Viel mehr schadet sogar.
Ausserdem würde ich testweise mal die Transaktionsprotokollierung ausschalten (falls eingeschaltet). Bei uns hat das was gebracht - zumindest unter 6.5.4FP2.
Grüsse.
-
Es ist nämlich nicht so, dass mehr Threads mehr Performance bringen.
Korrekt. Mein Reden! ;D
wenn der Peak bei 7 liegt, würde ich die Threadanzahl auf 10 oder max. 15 runtersetzen.
Das würde ich auf keinen Fall vorschnell machen! Den Peakwert von 7 hat JoJo erstmals nach meiner Aufforderung ermittelt. Er ist kein Indiz dafür, dass das bei ihm generell so ist. Es gibt mind. zwei Möglichkeiten warum er möglicherweise nur aktuell niedrig ist:
- derzeit wenig Web-Benutzer
- derzeit keine oder nur geringe Nutzung einer Webanwendung die durch ihre Architektur sonst viele Worker Threads beanspruchen würde
Hier sollte JoJo vorher noch analysieren bzw. uns die Infos geben, bevor er den Server mit 10-15 Threads möglicherweise dicht macht.
Grüßle
Daniel
-
na ja - bei einer Laufzeit von fast einer Woche ist das ja nun keine Momentaufnahme. Aber Recht hast Du - ich würde das auch noch etwas näher ansehen.
-
@Jojo,
Sorry schneller antworten ist zur Zeit für mich nicht d'rin. Ich arbeit im Second Level Support eines großen Rechenzentrums. Das ist ein wenig wie Fließbandarbeit. Und das Web-Server-Problem hat momentan nicht Priorität (s. o. Termin 31. 7.)
ist ok, aber ein SEHR schwaches Ergebnis des [großartigen] Rechenzentrums....
Du wirst mir das nicht krumm nehmen, aber ein RZ sollte das im Sitzen regeln. Ich kenne das RZ, ich nehm es dir deshalb auch nicht krumm.
Aber schwach ist das wirklich...
Wie klappts mit den Auszahlungen die letzten Tage und was machst du im 2L-Suppport ?!
Jo
-
Nochmals danke für die zahlreichen Rückmeldungen. So nun zum Offenen, wie gestern versprochen:
@HTTPQueueMethod: SEHR interessant. Das ist das erste was ich umsetzen werde, nachdem ich Daten über den Status Quo erhoben habe. Wenn das die Fehlerursache ist, wäre auch klar, weshalb die Performance-Probleme so unregelmäßig auftreten. Die Performance wäre dann wohl immer dann mies, wenn einer oder mehrere der ressourcenintensiven Agents läuft bzw. laufen.
@Serverdokument/Internet-Protokolle/Domino Web-Server - SITZUNGS-AUTHENTIFZIERUNG ist nicht aktiviert. Folglich kann ich auch leider nicht sagen, wie viele Benutzer gleichzeitig eine/die Webanwendung(en) verwenden. Klar, dass hier ein Blick auf die aktiven User im Admin-Client interessant ist. Heute um 16:20 waren es etwas mehr als zwanzig. 10:30 wäre freilich ein interessanterer Zeitpunkt, daß zu überprüfen.
@Was sind das für Webanwendungen? Z. B. Interne Formulare (Ansuchen um Urlaub,...) die nur übers Intranet zugänglich sind. Und sehr viele andere Applikationen, von denen ich eigentlich gar nichts weiß, ausser dass es sich (meist) um Workflow-Apps handelt. KEIN Web-Access, KEIN Notes-Mailing.
@Arbeitet ihr mit Caching? Weiß ich noch nicht. Muss ich erst herausfinden.
@Threadanzahl runtersetzen: ist zweifellos eine Option. Selbstverständlich werde ich vorher noch (mit Domino.Threads.Active.Peak) überwachen, welcher Wert maximal erreicht wird.
@Transaktionsprotokollierung deaktivieren: ist zweifellos keine Option, da es sich teils um sehr sensible Daten handelt.
@Jo: Generell: bitte beim technischen Thema bleiben oder in der Kategorie Offtopic einen eigenen Thread eröffnen (& mich bei Bearf via PM davon informieren). Vorerst: Wir haben aktuell ein Problem einen geeigneten neuen Kollegen für unsere WebServices-Abteilung zu finden. Folglich wird diese Abteilung von anderen Kollegen so weit wie möglich entlastet. Die Auszahlungen waren nie ein Problem. Du verwechselst mich mit jemanden.
-
Hi JoJo,
@HTTPQueueMethod: SEHR interessant. Das ist das erste was ich umsetzen werde, nachdem ich Daten über den Status Quo erhoben habe. Wenn das die Fehlerursache ist, wäre auch klar, weshalb die Performance-Probleme so unregelmäßig auftreten. Die Performance wäre dann wohl immer dann mies, wenn einer oder mehrere der ressourcenintensiven Agents läuft bzw. laufen.
Richtig. Das kann durchaus sein und ich möchte kurz erklären warum, vielleicht bringt es Dir oder jemandem der den Thread liest etwas:
Ab Domino 6.x wurde das HTTP Thread Queueing implementiert. Hier werden die eingestellten Worker Threads einfach von 1 - X durchnummeriert und der HTTP Accept Thread, der die eingehenden HTTP Requests annimmt, geht per round robin von 1 - X durch und verteilt die Requests an die Worker Threads. Ist er bei X angelangt, fängt er wieder bei 1 an usw. Nun kann es natürlich sein, dass aber Thread Nr. 1 oder irgendeiner danach, noch mit einem Request beschäftigt ist, der längere Zeit dauert (die Klassiker währen hier z.B. Dateidownloads oder etwas länger dauernde Webagenten). Das interessiert in diesem Fall den Accept Thread nicht und er stellt den nächsten HTTP Request einfach hinter den noch laufenden in eine Queue. Somit muss ein armer Benutzer, der eigentlich nur eine 3K große HTML Seite öffnen will warten, bis der Thread mit dem Langläufer fertig ist.
Dieses Thread Queueing kann also bei einem stark frequentierten Domino 6.x Webserver < 6.5.5, mit Webanwendungen die entsprechend lang dauernde Requestarten beinhalten können, durchaus zum Ärgernis führen.
Die mögliche Lösung ist die ab der Version 6.5.5 einstellbare HTTPQueueMethod. Z.B.
HTTPQueueMethod=2
bewirkt, dass der HTTP Accept Thread aus dem Connection Pool, der die anstehenden HTTP Requests zur Abarbeitung beinhaltet, diese herauspickt und dem nächsten FREIEN Worker Thread zuordnet. Hier, wäre also erst dann ein Queueing-Verhalten gegeben, wenn ALLE Worker Threads etwas zu tun haben, was in der normalen Queue-Variante keineswegs immer der Fall wäre.
Diese Methode ist also gleichzeitig mit Vorsicht zu genießen, da erstens die Anzahl der gleichzeitig genutzten Worker Threads ansteigen kann und dem entsprechend auch die Hardwareauslastung des Dominoservers.
Mit der HTTPQueueMethod=2 konnten wir im Lasttest einer Domino Webanwendung, einen HP Compaq ProLiant ML570 G2, 4x 2,8GHz Xeons (HT=8) und 4GB RAM in der CPU Auslastung an den Anschlag bringen. 100% über alle CPUs und 400MB mehr Speicherallocation beim HTTP Task (von normalerweise 800MB auf 1200MB). Der Lasttest beinhaltete freilich unwahrscheinliches Benutzerverhalten (250 gleichzeitige Benutzer, die ohne Thinktimes permanent Requests abgesetzt haben), hat aber gezeigt, dass hier noch immenses Potential für die Ausnutzung der Hardware durch Domino bestand. Ohne die QueueMethod=2 hat der Server sich meist mit 2-3 CPUs gelangweilt und es waren weitaus weniger hits/s möglich.
@Serverdokument/Internet-Protokolle/Domino Web-Server - SITZUNGS-AUTHENTIFZIERUNG ist nicht aktiviert. Folglich kann ich auch leider nicht sagen, wie viele Benutzer gleichzeitig eine/die Webanwendung(en) verwenden. Klar, dass hier ein Blick auf die aktiven User im Admin-Client interessant ist. Heute um 16:20 waren es etwas mehr als zwanzig. 10:30 wäre freilich ein interessanterer Zeitpunkt, daß zu überprüfen.
Ja, wäre schön gewesen das zu wissen. Die Anzahl der Notes Benutzer lassen ja keinen Rückschluss zu, ob diese auch gleichzeitig über Web auf dem Server arbeiten. Die QueueMethod=2 auf gut Glück zu verwenden, ohne die genaue Anzahl der gleichzeitigen Webuser zu kennen, birgt meines Erachtens jedoch kein all zu großes Risiko. Bei einem durschnittlich stark frequentierten Domino Webserver, sollte sich das Verhalten, wenn überhaupt, positiv bemerkbar machen. Vorausgesetzt, die eingestellten Worker Threads reichen aus, um die Anfragen zeitnah abzuarbeiten. Ich würde den Test auf jeden Fall mit dem Standard von 40 beginnen.
@Arbeitet ihr mit Caching? Weiß ich noch nicht. Muss ich erst herausfinden.
Caching von sich selten ändernden Elementen wie Bilder und JS-Dateien auf Proxys oder lokal auf den Clients, kann natürlich auch einiges an Performance bringen, wenn die Anwendung häufig genutzt wird. Hier wird leider öfters mal vom Entwickler der Webanwendung nicht bedacht, dass HTTP Headervariablen wie z.B. cache-control (http://www.bolege.de/http-header/) mit den entsprechenden Parametern, Wunder bewirken können. Wenn es nicht möglich ist, diese Variablen schon in der Anwendung in die Header einzubauen, kann das auch der Dominoserver übernehmen. Hierzu gäbe es dann die Web Site Rule vom Typ "HTTP response headers", die vorhandene Header überschreiben oder selbst welche hinzufügen kann. Hier ist zu beachten, dass sich das durchaus auf die Performance des Dominoservers und auch die einer Webanwendung durchschlagen kann, da der Server auf jeden Request anhand des Response Codes (z.B. 200 für OK) reagieren und den Header hinzufügen oder überschreiben muss.
Viele Grüße
Daniel
P.S.: Oh Gott ist das viel Text :-\, liest das überhaupt einer? ;D
-
@Transaktionsprotokollierung deaktivieren: ist zweifellos keine Option, da es sich teils um sehr sensible Daten handelt.
Die Begründung kann ich nicht nachvollziehen. Die Transaktionsprot. verringert sicher die I/O-Last und ist bei Server-Crashs hilfreich, aber dass eine höhere Datensicherheit herbeigeführt wird, wäre mir neu.
Grüsse!
-
Oh Gott ist das viel Text :-\, liest das überhaupt einer? ;D
Ja. Da ich nun aber eigentlich noch Freizeit habe, antworte ich erst später. Schon jetzt danke, dass du dich hier nach wie vor so engagierst.
Die Begründung kann ich nicht nachvollziehen. Die Transaktionsprot. ..., aber dass eine höhere Datensicherheit herbeigeführt wird, wäre mir neu.
Einer der von IBM am meisten angepriesenen Vorteile der TP ist, dass FIXUP nach einem Sever-Ausfall meist nicht gebraucht wird. Dies deckt sich mit meiner Beobachtung von Neustarts von Servern, die TP verwenden. FIXUP bereinigt DBen um "korrupte" (= defekte) Dokumente. Bereinigt heisst aber, dass es sie nachher nicht mehr gibt. Wenn man also FIXUP nicht mehr/seltener benötigt, verschwinden weniger Dokumente.
-
Laut http://www-1.ibm.com/support/docview.wss?uid=swg21201715:
With this change in 6.5.4 FP1, and 6.5.5, we are allowing the option to change how threads process HTTP connections.
Vor kurzem habe ich daher bei unserem Server (6.5.4FP2) an der Konsole
set configuration HTTPQueueMethod=2
tell http restart
eingegeben. Morgen ist der Monatsletzte. Da sollte es dann schon ein erstes relevantes Feedback der User geben. Sobald das da ist, meld' ich mich nochmals (ausführlicher).
-
Ups... dass das Feature bereits ab 6.5.4FP1 vorhanden ist, hab ich bisher großzügig überlesen.
(Hoffentlich isses in 6.5.4FP2 nicht wieder ausgebaut ;D)
Danke ;)
Daniel
-
Der erste Tag brachte keinen besonderen Ergebnisse. Der Mann, der das Feedback einfordern soll, hatte nix zu berichten. Daraus resultiert aber unter anderem, dass der Wert von HTTPQueueMethod auf 2 bleibt.
Meine Test-Zugriffe verliefen allesamt ohne wirklich lange Wartezeiten. Einzig das IBM-Applet verursachte beim ersten Öffnen einer DB Wartezeiten im Bereich einiger Sekunden. Interessant wäre, ob hier mit Caching ein Verbesserung erreichbar ist.
Leider fehlte mir jedoch wieder mal die Zeit, um mich darum (Caching) oder irgendwas abseits des Alltagsgeschäfts zu kümmern. Nur noch kurz zu Dokumentationszwecken einige Details:
OS: W2k-AdvancedServer
CPU: 4 x 2,8 GHz
RAM: 2,5 GB
-
Neben der oben beschriebenen notes.ini-Änderung wurde bisher Folgendes durchgeführt:
Beim http-Zugriff auf die Workflow-DB wurde ursprünglich VOR dem Zugriff auf diese DB auf einen der beiden (das Portal bildende,...) Intranet-Server (Apache) zugegriffen. Diese haben dann die Anfrage an den Notes-Workflow-Server weitergeleitet. Diese Weiterleitung dauerte oft sehr lange. Nun wird direkt auf den Notes-Workflow-Server zugegriffen.
Diese beiden Änderungen brachten insofern etwas, als die langsamen Zugriffe nun seltener geworden sind. Dennoch gibt es noch immer ab und zu lähmende Response-Zeiten. Dafür dürfte jedoch das Design verantwortlich sein. Es wird nun nochmals überarbeitet.