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?
