Mail weiterleiten inkl. Anhänge dauert ungewöhnlich lang

[TimDom]

Hi Tom,

ich habe gerade mal bei mir geschaut.
In meinem pers. Adressbuch gibt es Verbindungsdokumente zum alten als auch zum neuen Server.
Merkwürdigerweise sind da mehr als 1 pro Server und auch noch als "Notes Direct Dialup". Wie auch immer die da hin gekommen sind.
Es gibt aber auch "normale" Verb.-dokumente zu den beiden Servern. Und das zu dem alten Server brauchen wir auch, da da noch andere Datenbanken liegen.

Die Modemdokumente habe ich nun mal geslöscht und den Client neu gestartet.
Laut "Stoppuhr" dauert es immer noch 1:15 bis die 9 MB Mail weitergeleitet wird.

@Ralf:

Schau mal in dem Posting hier:

http://atnotes.de/index.php/topic,54531.msg352057.html#msg352057

Da habe ich das Log mal anonymisiert angehangen. Eventuell findest Du da ja den Knackpunkt.

Auch hier ein wenig Off-Topic:

Wie kann ich denn in einer PM einen Anhang anhängen?
Ich finde da nicht wirklich einen Button, wie hier uner den "Erweiterten Optionen".

[Ralf_M_Petter]

Sorry das File habe ich zuerst übersehen. Nun laut dem Client clock log dauern die Readobject alle viel zu lange. Ich habe dein Szenario bei mir nachgestellt mit einem Attachment in der Größe von 8 MB und jeder ReadObject dauert unter 5 ms und die meisten dauern sogar nur 1 -2 ms. Ich denke mal du hast hier ein Netzwerkproblem. Kontrolliere mal auf deinem Switchport ob irgendwelche Fehler mitprotokolliert werden. Falls das nichts ergibt trace mit Wireshark den Netzwerkverkehr während du die Weiterleitungsaktion machst. Dann solltest du klarer sehen. Du kannst einen Filter mit Zielport 1352 setzen um den ganzen andern Netzwerkverkehr auszublenden.

Grüße

Ralf

[RZLT]

Die Einträge in den Verbindungsdokumenten passen auch?
Hast Du den Pfad zum Mailverzeichniss überprüft, da in dem Log-Auszug was mit "File does not exist" auftaucht.

[TimDom]

Hi Ralf,

na da bin ich mal gespannt, was unsere Netzerwerker dazu sagen.
Auf jeden Fall sind Deine Werte mal wirklich klasse. Da wäre ich mal froh, wenn wir annährend da dran kämen.

@Tim:

Die Verbindungsdokument sind korrekt. Name und IP Adressen stimmen.
Allerdings würde da das DNS auch korrekt auflösen.

Und das "File does not exist" bezieht sich ja auf die roamingdata.nsf aus dem Roaming Verzeichnis des Benutzers.

[DigitDani]

Moin Tim,

Punkt 1: Checked und auf beiden Seiten Off

Port compression einzuschalten macht unbedingt Sinn, solange man Notes nicht auf Citrix betreibt. Dort kann die leicht höhere CPU und RAM Auslastung schnell zu Deadlocks führen. Fat-Clients und aktuelle Server können damit aber generell sehr gut umgehen und Du hast 20-30% weniger Netzlast. Unbedingt aber auf beiden Seiten aktivieren, sonst müssen RPC Calls unnötigerweise mehrmals geschickt werden bevor die Gegenseite sie versteht.

Das mit dem alten Server ist zwar unschön, kann aber bei der Betrachtung hier ausser Acht gelassen werden. Der Client versucht nur beim Start und Beenden mit diesem Server zu kommunizieren und benötigt dafür nur einige wenige ms.

Zuerst stimme ich mal Ralf zu, ihr habt sehr wahrscheinlich ein Netzwerkproblem (mind. schlechte Latenzwerte):

Code

[0F88:0002-085C] (179-27 [180]) READ_OBJECT(REPC1257111:004367D3-RRV00013ED2,0xF000 at 0x2D000): 103 ms. [26+61610=61636]
[0F88:0002-085C] (188-27 [189]) READ_OBJECT(REPC1257111:004367D3-RRV00013ED2,0xF000 at 0xB4000): 204 ms. [26+61610=61636]

Solche Werte sind für ein LAN viel zu hoch - knapp 60kb in über 100ms sind maximal für WAN Verbindungen über DSL etc. normal.

Da zwischendurch aber auch immer bessere Werte (3-8ms) zu finden sind - allerdings für das Lesen eines Objektes innerhalb des selben Dokumentes - tippe ich auch auf fehlerhaft konfigurierte Netzwerkomponenten wie Switche oder Netzwerkkarten. Sieht aus wie Schluckauf

Ganz schlau werde ich aus Deinem RPC-Log aber letztlich trotzdem nicht. Ich sehe nirgends Datenmengen von mehreren MB die gesendet werden (höchstens als Summe aus mehreren Calls), geschweige denn Wartezeiten im Minutenbereich.

Hast Du die Mail während der Aufzeichnung des Logs auch wirklich versendet?
Besteht die 8-9MB große Mail aus mehreren Attachments? Sieht im Log nämlich so aus.

Wie auch immer, mit den Netzern zu sprechen sollte Prio 1 sein.

vlg

[TimDom]

Mahlzeit Daniel,

schon mal vielen Dank für Deine Hilfe/Infos.
Natürlich auch Danke an alle, die hier ihre Kommentare bzw Tips abgegeben haben.

Gesendet habe ich die Mail nicht, als ich das Log erstellt habe. Denn alleine der Druck auf "Weiterleiten" hat bei mir ja schon mehr als eine Minute gebraucht.
Und ja, die Mail besteht aus mehreren (10) "kleineren" PDFs. In Summe sind das dann ca 9,6MB.
Es gibt aber auch andere Mails unterschiedlicher Anzahl von Anhängen, wo das reproduzierbar ist.

Wie dem auch sei.
Ich werde mal die Jungs ansaugen die sollen mal schauen und sniffen, was da so abgeht oder auch nicht.

Wenn's Neuigkeiten jeglicher Art gibt, melde ich mich wieder.

[DigitDani]

Mahlzeit

Gut, dann macht das hier nämlich Sinn:
Auszug Start:

Code

[0F88:0002-085C] (25-17 [26]) OPEN_NOTE(REPC1257111:004367D3-NT000137CE,02400136): 6 ms. [48+31948=31996]
[0F88:0002-085C] (26-17 [27]) GET_OBJECT_SIZE(REPC1257111:004367D3): 1 ms. [200+24=224]
[0F88:0002-085C] (27-17 [28]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0x0): 16 ms. [26+61610=61636]
[0F88:0002-085C] (28-17 [29]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0xF000): 103 ms. [26+61610=61636]
[0F88:0002-085C] (29-17 [30]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0x1E000): 105 ms. [26+61610=61636]
[0F88:0002-085C] (30-17 [31]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0x2D000): 205 ms. [26+61610=61636]
[0F88:0002-085C] (31-18 [32]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0x3C000): 320 ms. [26+61610=61636]
[0F88:0002-085C] (32-18 [33]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0x4B000): 9 ms. [26+61610=61636]
[0F88:0002-085C] (33-18 [34]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0x5A000): 8 ms. [26+61610=61636]
[0F88:0002-085C] (34-18 [35]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0xF000 at 0x69000): 107 ms. [26+61610=61636]
[0F88:0002-085C] (35-18 [36]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9A,0x81DD at 0x78000): 4 ms. [26+33346=33372]
[0F88:0002-085C] (36-18 [37]) GET_OBJECT_SIZE(REPC1257111:004367D3): 0 ms. [200+24=224]
[0F88:0002-085C] (37-18 [38]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x0): 114 ms. [26+61610=61636]
[0F88:0002-085C] (38-18 [39]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0xF000): 103 ms. [26+61610=61636]
[0F88:0002-085C] (39-18 [40]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x1E000): 7 ms. [26+61610=61636]
[0F88:0002-085C] (40-18 [41]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x2D000): 105 ms. [26+61610=61636]
[0F88:0002-085C] (41-18 [42]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x3C000): 6 ms. [26+61610=61636]
[0F88:0002-085C] (42-18 [43]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x4B000): 7 ms. [26+61610=61636]
[0F88:0002-085C] (43-18 [44]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x5A000): 6 ms. [26+61610=61636]
[0F88:0002-085C] (44-18 [45]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x69000): 7 ms. [26+61610=61636]
[0F88:0002-085C] (45-18 [46]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0xF000 at 0x78000): 7 ms. [26+61610=61636]
[0F88:0002-085C] (46-18 [47]) READ_OBJECT(REPC1257111:004367D3-RRV00013E9E,0x2766 at 0x87000): 97 ms. [26+10126=10152]
[0F88:0002-085C] (47-18 [48]) GET_OBJECT_SIZE(REPC1257111:004367D3): 1 ms. [200+24=224]
[0F88:0002-085C] (48-18 [49]) READ_OBJECT(REPC1257111:004367D3-RRV00013EA2,0xF000 at 0x0): 16 ms. [26+61610=61636]
[0F88:0002-085C] (49-18 [50]) READ_OBJECT(REPC1257111:004367D3-RRV00013EA2,0xF000 at 0xF000): 7 ms. [26+61610=61636]
[0F88:0002-085C] (50-18 [51]) READ_OBJECT(REPC1257111:004367D3-RRV00013EA2,0xF000 at 0x1E000): 103 ms. [26+61610=61636]
[0F88:0002-085C] (51-19 [52]) READ_OBJECT(REPC1257111:004367D3-RRV00013EA2,0xF000 at 0x2D000): 106 ms. [26+61610=61636]
[0F88:0002-085C] (52-19 [53]) READ_OBJECT(REPC1257111:004367D3-RRV00013EA2,0xF000 at 0x3C000): 6 ms. [26+61610=61636]
[0F88:0002-085C] (53-19 [54]) READ_OBJECT(REPC1257111:004367D3-RRV00013EA2,0xC23E at 0x4B000): 103 ms. [26+49866=49892]

Auszug Ende

Hier werden diese ganzen Attachments in kleine KB-Teile zerlegt und vom Client eingelesen. Hier siehst Du dann deutlich den Schluckauf, auch während des Lesens eines einzelnen Attachments.

Viel Erfolg beim Schnüffeln

[TimDom]

Hallo zusammen,

es gibt eine Lösung meines Performanceproblems.
Und zwar hat zwischenzeitlich DigitDani viel Support geleistet und mir versucht bei dem Problem zu helfen. Letztendlich kamen wir dann wohl auch auf die richtige Fährte.

Getestet haben wir mittlerweile mit einer leeren DB auf dem Domino. Da dann eine Maske mit einem Richtextitem rein. Dann ein neues Dokument erstellt, da ein ca 8 MByte Anhang dran und speichern.
Der Speicherprozess hat ca 50 Sekunden gedauert. Toll oder?

Jetzt muss ich sagen, dass die Dominos auf SLES 11 laufen. Naja, mal versuchsweise die Test DB auf einen Windowsdomino geschoben (wo der BlackBerry drauf läuft) und was soll ich sagen. In 5 Sekunden war das Dokument fertig. War jetzt was für unsere Windowsfraktion.  konnten die sich nicht verkneifen.

Dann noch mittels Google folgenden IBM Artikel gefunden.

http://www-01.ibm.com/support/docview.wss?uid=swg1LO67375

Der beschreibt zwar nicht zu 100% unser Problem, aber egal.
Heute morgen dann bei IBM einen PMR aufgemacht, 1 Stunde später hatte ich den ersten Mailkontakt. Dann ca 2 Stunden später nach Überprüfung der Versionen einen Hotfix.
Den habe ich eben auf unseren Dominos im Cluster eingespielt. Und nun rocken die Dominos auch unter Linux. 8 MB, 9MB … kein problem mehr.   

Also ich muss mal sagen. Dass ich bei meinem ersten PMR direkt solch einen Erfolg hatte, hat mich mal echt überrascht. Hut ab IBM.

Damit noch mal herzlichen Dank an alle, die hier geholfen haben.
Im speziellen aber DigitDani. Die Hilfe ging schon über ein normales Forum raus

Danke und Gruß