Domino 9 und frühere Versionen > ND6: Administration & Userprobleme

Domino 6.5.3FP1 - http-Performanceprobleme ?

<< < (5/7) > >>

DigitDani:

--- Zitat von: knoedel0815 am 27.06.06 - 18:41:16 ---Es ist nämlich nicht so, dass mehr Threads mehr Performance bringen.

--- Ende Zitat ---
Korrekt. Mein Reden!  ;D


--- Zitat von: knoedel0815 am 27.06.06 - 18:41:16 ---wenn der Peak bei 7 liegt, würde ich die Threadanzahl auf 10 oder max. 15 runtersetzen.

--- Ende Zitat ---
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

knoedel0815:
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.

ascom40:
@Jojo,


--- Zitat ---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.)
--- Ende Zitat ---

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

JoJo:
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.

DigitDani:
Hi JoJo,


--- Zitat von: JoJo am 28.06.06 - 16:40:57 ---@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.

--- Ende Zitat ---
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.


--- Zitat von: JoJo am 28.06.06 - 16:40:57 ---@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.

--- Ende Zitat ---
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.


--- Zitat von: JoJo am 28.06.06 - 16:40:57 ---@Arbeitet ihr mit Caching? Weiß ich noch nicht. Muss ich erst herausfinden.

--- Ende Zitat ---
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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete