[Wireshark] Waar komt deze 'vertraging' door?

[De_Bastaard]

Hoi Allemaal,

Op mijn werk verkopen we als partner document management software. Nu komen we echter bij één klant een vertraging tegen bij het openen van documenten en we hebben eerlijk gezegd geen idee waar het vandaan komt.

Ik heb nu net met Wireshark het e.e.a. getest, en ik zie dat er een vertraging van enkele seconden zit (time van het ene packet tot het andere schiet van 0.48 naar 3.41 seconden), terwijl het maar een document betreft van 80kb.

In Wireshark zelf zie ik nu wel enkele meldingen over ICMP en over UDP, maar volgens mij zijn die niet zo denderend dat er daar 2 seconden vertraging door kan optreden.

Kunnen jullie me misschien zeggen hoe ik onderstaande informatie moet interpreteren, want wat mij betreft gaat het gewoon goed.

Even ter informatie, ik heb de TCP Checksum uitgezet omdat ik daar wel enkele 'errors' van voorbij zag komen. Misschien dat een driver update dat kan verhelpen.

Overigens vraag ik niemand hier om mijn werk op te lossen, ik hoop dat iemand me kan vertellen wat ik nog meer kan onderzoeken :-)

[NeHoX]

ICMP is een pingetje. Netwerkdrivers updaten en/of kabel doormeten.

[De_Bastaard]

Even nog als extra info, alles draait daar in Hyper-V en waarschijnlijk op dezelfde SAN.

De Server software en de FileStore staan overigens op dezelfde virtuele machine. De client maakt van verbinding met de Server (duh), waarna het document wordt geopend vanaf de FileStore en dan naar de client gestuurd wordt nadat deze eerst door enkele temp folders gegaan is.

[Verwijderd]

Als de .181 de client is dan wacht de client zelf die paar secondes en ligt het niet aan je server.
'Time' houdt niet in hoe lang het duurt maar wanneer het plaatsvindt vanaf het moment dat je de capture start.

[De_Bastaard]

Klopt, de .181 is inderdaad de client (in dit geval een Citrix server, gehost in hetzelfde datacenter).

[TrailBlazer]

er wordt gewoon een 2e sessie opgestart na 3 seconden waarbij er eerst een UDP sessie opgezet wordt maar er luistert niks op die specifieke UDP poort. Lijkt applicatieprobleem te zijn.

[De_Bastaard]

Waar ik zelf nog aan dacht, was of de Domain Controller er misschien mee te maken kan hebben? Volgens mij regelt die de autorisatie tot bepaalde documenten. Misschien dat die het niet bij kan benen?

Daarnaast zie ik in WireShark regelmatig een [TCP Window Update] voorbij komen. Kan dit aanduiden dat de TCP Buffer van de ontvangende partije niet groot genoeg is Het zijn allemaal Citrix servers waar zo'n 10 man op werken, als die allemaal aan 't werk zijn kan dat natuurlijk wat traffic veroorzaken.

[Eagle Creek]

Wat voor bestand is het? In bepaalde versies van Excel zit een bug waarbij het openen van bestanden op netwerkshares een vertraging oplevert. Daar is een update voor.

Als het een dusdanig specifiek probleem is, haal je dat er niet uit met een programma als draadhaai .

[De_Bastaard]

Het komt bij verschillende documenten voor :-)

Het bestand waar ik het mee getest heb is een PDF van 80kb, maar de delay merk je ook bij Word/Excel/etc.

[Bor]

Ik zou eerst naar die port unreachable kijken. Het lijkt dat er een connectie word opgezet naar een poort waar niets op staat te luisteren. Kijk je niet gewoon tegen een timeout oid aan daar?

[TrailBlazer]

nee want die poging op die UDP poort komt pas na de vertraging van 3,5 seconde

[De_Bastaard]

Die port unreachable komt overigens alleen voor wanneer ik op de server zelf Wireshark draai. Op de client komt deze niet terug. De client heb ik als deel van het troubleshooten al zo geconfigureerd dat UDP niet gebruikt wordt, en er alleen via TCP gecommuniceerd mag worden.

[Brahiewahiewa]

Kun je het probleem reproduceren op een client waar geen virusscanner op draait?

[De_Bastaard]

Als het goed is draaien de clients geen virusscanner, de servers al helemaal niet.

Ik krijg btw ook de melding 'Please wait while trying to find the registered servers' (melding van de software zelf). Dit zagen we wel eens vaker, en konden worden veroorzaakt doordat de client wilde zoeken naar een server via UDP en dan via TCP. Om dat al uit te sluiten maakt de client nu uitsluitend verbinding via TCP.

[WhizzCat]

TCP Window sizes etc. al nagelopen? Met Dr TCP en iperf kan je ook vrij fatsoenlijk performance meten van alleen het netwerk. Als dit in orde is moet er dus ergens anders gezocht worden

[De_Bastaard]

Wat zou de Window Size moeten zijn als ik iperf gebruik ? Ik krijg op de clients met -c -w 2000 terug dat de Window Size 1.98KB/Sec zou zijn. Op de Server is dit 3.9, maar daar gebruik ik dan ook de waarde 4000.

[TrailBlazer]

windowsize zit het probleem niet in. Daar moet je enkel naar gaan kijken bij low latency verbindingen binnen een lokatie maar heel zelden een probleem.

[leuk_he]

De_Bastaard schreef op maandag 23 april 2012 @ 11:52:
Die port unreachable komt overigens alleen voor wanneer ik op de server zelf Wireshark draai. Op de client komt deze niet terug. De client heb ik als deel van het troubleshooten al zo geconfigureerd dat UDP niet gebruikt wordt, en er alleen via TCP gecommuniceerd mag worden.

Komt die icmp niet op de client terug? staat er dus een of andere firewall tussen die te veel filtert? zoals icmp berichten over port unreachable, window size.....

zondermeer is het prettig om te kijken met wireshark op een client of er in die 3,5 seconde nog iets gebeurd op het netwerk, zoals een authorisatie request naar ... whatever....

[ Voor 13% gewijzigd door leuk_he op 24-04-2012 16:14 ]

[De_Bastaard]

Thanks,

Dat zal ik even onderzoeken. Windows firewall is in elk geval uitgeschakeld, daar kan het niet aan liggen. Misschien inderdaad toch 'n andere firewall die de boel verpest....

[ Voor 22% gewijzigd door De_Bastaard op 24-04-2012 16:30 ]

[Verwijderd]

Om iets zinnigs te kunnen roepen hierover zul je toch echt een iets completere capture moeten laten zien, op basis van deze paar pakketten is de conclusie namelijk: applicatie is zelf traag.
Communicatie met een domaincontroller kan de boel inderdaad vertragen (zou niet moeten, maar kan) maar aangezien dat niet te zien is in je screenshot valt er weinig zinnigs over te roepen.

edit:

die icmp unreachable is trouwens niet heel interessant, die melding krijg je namelijk omdat het vorige pakketje (een udp verbinding) niet aankomt omdat er niets luistert op die poort.
Omdat UDP geen syn/ack mechanisme heeft weet de bron zelf niet dat het pakket niet aankomt en dat wordt dan weer opgelost door een icmp terug te sturen met de 'port unreachable' melding.

Zie ook: Wikipedia: ICMP Destination Unreachable

edit2:

Het lijkt er overigens op dat die .146 een proxy server is.. klopt dat? Zoja zit daar je probleem en zal je wat moeten openzetten / daar moeten gaan monitoren.

[ Voor 48% gewijzigd door Verwijderd op 24-04-2012 20:30 ]

[De_Bastaard]

De .146 is de destination server en de .181 is de client.

181 maakt verbinding met de 146, die op zijn beurt weer wat doet met SQL.

Vandaag is er wat geheugen in de Domain Controller bijgeprikt, maar dat heeft geen verschil gemaakt. Ik zal morgen kijken of ik een complete log kan maken :-)

[De_Bastaard]

Ik heb het gedrag volgens mij een aantal keer goed weten te reproduceren, en merk echt dat Outlook een tijdje 'not responding' is. Als ik Procmon gebruik zie ik dat bepaalde handelingen opeens bijzonder lang duren.

We hebben nu een nieuwe testclient (win2k8 server standard) ingericht, waarvan het IP 172.16.26.161 is. Deze maakt verbinding met de .146 (de echte server).

Wireshark dump. De vertraging begint bij mij volgens mij pas vanaf Event 7000. : http://www.bassius.nl/got/wiresharkdump.pcap

Procmon dump : Hier zie ik volgens mij duidelijk een vertraging vanaf 1:33:54 naar 1:33:58 http://www.bassius.nl/got/Logfile_Procmon.CSV

De logs/dumps zijn overigens niet op hetzelfde moment genomen, maar zijn wel van dezelfde actie. Ik kan die wel uploaden, maar dan zie je een enorme lading aan overbodige informatie omdat Wireshark en Procmon elkaars handelingen ook zitten te loggen.

[Verwijderd]

Heb hem nog niet heel erg goed bekeken maar ik zou hem maar weer offline gaan gooien.. hier staat wel erg veel informatie in die je echt niet zomaar op internet moet knallen.

Maar inderdaad, de melding "Crash Outlook op BOLRDS03 graag oorzaak hiervan achterhalen" moet onderzocht worden, melding 21784.

Zal er in ieder geval eens induiken, kan je misschien iets krapper aangeven wat het moment is dat je een file upload? Ik zie wel heel veel meldingen opgehaald worden namelijk.

edit: als je procmon draait vertraagt dat alles op je systeem, performance monitoren met procmon is niet heel erg handig (understatement).

[ Voor 12% gewijzigd door Verwijderd op 25-04-2012 16:33 ]

[De_Bastaard]

Hey Mental,

Ik heb de files even offline gehaald :-)

Wat ik doe, is eigenlijk al zéér krap. Ik kan hooguit de capture wat verkleinen en alleen het moment waarop de vertraging volgens mij zichtbaar is, maar ik weet niet zeker of jullie dan genoeg informatie hebben.

De stap die ik onderneem is:

- Clear log;
- Start capture;
- Meteen de actie uitvoeren;
- Zodra Outlook weer reageert, stop ik de capture.

Kost pakweg 8-10 seconden, maar in die tijd is Outlook in elk geval bezig/not responding.

Edit:

Alternatief voor procmon toevallig?

[ Voor 4% gewijzigd door De_Bastaard op 25-04-2012 16:36 ]

[Verwijderd]

Kun je nog aangeven wat die actie dan precies is?

edit: ook al gekeken in C:\Users\sjeft\AppData\Local\Temp\2\FileSite_EM\Logs\ ? Staat daar nog wat zinvols in?

edit: geen alternatief nee, dit ga je ook met andere process monitoring tools krijgen.

[ Voor 74% gewijzigd door Verwijderd op 25-04-2012 17:09 ]

[De_Bastaard]

Ik zie daar wel een log, maar die geeft geen uitsluitsel. Morgen ga ik maar eens bellen met de leverancier, misschien hebben ze daar een idee. Na wat register geknutsel lijkt het wat minder te zijn, althans de melding 'not responding' zie ik niet meer terug. Outlook *denkt* wel nog een paar seconden... misschien kan hun IT partner een netwerktechnicus er eens naar laten kijken want het lijkt volgens die logs wel steeds te vertragen bij tcp verkeer over poort 5xxxx.

Alvast enorm bedankt voor de hulp so far :-)

[Verwijderd]

Waar haal je dat uit?
Bedoel je dat outlook blijft hangen op het moment dat die gigantische hoeveelheid verkeer over die poort start en pas weer reageert als dat afgelopen is?
Klinkt echt als een applicatieprobleem (als in, teveel wilen doen op een moment dat outlook op je zit te wachten tot je klaar bent).
Het is niet dat er op de achtergrond niets gebeurd op het moment dat outlook blijft hangen, het is meer dat het te lang duurt waardoor outlook even niet reageert.
Als ik het me goed herinner heeft FileSite hier altijd al last van gehad op moment dat je veel folders / files in een folder hebt staan.

[webfreakz.nl]

De_Bastaard schreef op woensdag 25 april 2012 @ 18:35:
Ik zie daar wel een log, maar die geeft geen uitsluitsel. Morgen ga ik maar eens bellen met de leverancier, misschien hebben ze daar een idee. Na wat register geknutsel lijkt het wat minder te zijn, althans de melding 'not responding' zie ik niet meer terug. Outlook *denkt* wel nog een paar seconden... misschien kan hun IT partner een netwerktechnicus er eens naar laten kijken want het lijkt volgens die logs wel steeds te vertragen bij tcp verkeer over poort 5xxxx.

Alvast enorm bedankt voor de hulp so far :-)

Een netwerktechnicus hoeft hier niet naar te kijken, tenzij er een firewall tussen client / server staat, maar dat lijkt me sterk.

Wat je hier nodig gaat hebben zijn een debugger op je applicatie danwel DEBUG build van je applicatie danwel een logboek die informatie geeft.

Er zijn twee zaken die onderzocht moeten worden:

• De delay van 3 seconden, waarna een UDP verbinding gestart wordt. Dit moet heus wel in de broncode van de software te herleiden zijn. Er moet namelijk gespecificeerd worden of je TCP danwel UDP wilt gebruiken.
• Die ICMP Port-Unreachable kan veroorzaakt worden door een firewall met een rule die "Reject" doet. Lijkt me sterk dat je een firewall hebt. Anders duidelijk applicatie probleem omdat je applicatie op de server niet goed aan juiste port (Port2637 volgens http://www.corrupteddatar...ype-imdocsvc-imdocsvc.asp ) gebonden is. Doe eens "netstat -ano | findstr 2637" en herleid het PID met Task Manager terug naar de applicatie.

Beide zijn zaken waar de leverancier van je software je in zal moeten ondersteunen.

Een netwerktechnicus gaat echt niks vinden, die zal met met een "nmap -p 2637 -sU 172.16.26.146" een makkelijk dagje hebben

[De_Bastaard]

Nou,

Ik heb vandaag nog eens gechecked maar de Windows Firewall staat uit. Dat zou eventueel betekenen dat hun IT partner toch nog ergens een poort blokkeert. Ervaring uit het verleden laat mij denken dat dit bij hen inderdaad het geval kan zijn.

De client checkt standaard op servers via tcp en udp. Ik heb deze inmiddels zo geconfigureerd dat er alleen via tcp verbinding moet worden gemaakt (standaard poorten voor deze software zijn 1080 en 1081). Het zou mogelijk kunnen zijn dat niet alle poorten open staan... maar dan zou de actie toch helemaal moeten mislukken ?

[leuk_he]

het feit dat je die icmp message "port unreachable" wel ziet op de server, maar niet op de client lijkt eerder een indicatie dat er een firewall (/switch) icmp protocol verkeer blokkeert. Niet ongebruikelijk dat een switch niet al het verkeer doorlaat (een wilde dhcp server is een drama!), maar wellicht dat hier teveel gefiltert word.

[Verwijderd]

Nee leuk_he, dat is pure onzin.
Dat icmp pakket komt vanaf de server nadat een udp pakket vanaf de client niet aankomt op de server.
UDP is helaas geen protocol dat een syn/ack doet dus stuurt de server een icmp pakket met de mededeling 'port unreachable' terug.
Zie ook de opmerking (met link naar wikipedia met uitleg) van een paar posts geleden.

ps. een switch laat al het verkeer door, een router/firewall daarintegen niet.

edit: port 1080 staat ook gewoon open en er is ook verkeer.
Je applicatie werkt toch ook gewoon? Ik zie in je capture geen verkeer langskomen wat geblokkeerd wordt vanaf de client naar de server toe.
Komt nog bij dat ze in het zelfde subnet staan dus óf er staat een firewall op de server die wat tegenhoud óf alles mag gewoon aangezien er geen hardware firewall / router tussenzit.

edit2: je zou eventueel even op je server je antivirus kunnen nalopen of die niet toevallig realtime protection doet op de locatie waar die documenten staan.

[ Voor 48% gewijzigd door Verwijderd op 25-04-2012 23:01 ]

[De_Bastaard]

Hey Mental,

Klopt, de applicatie werkt gewoon. Ik krijg geen foutmeldingen dat bestanden niet kunnen worden verstuurd of dat er onderweg iets mis gaat. Het duurt alleen enorm lang om een klein bestand te 'filen', iets wat we totaal niet zien bij andere (nog grotere) klanten. Ik heb dan ook zo'n vermoeden dat er haast wel iets mis moet zijn in de omgeving van de klant, maar hoe of wat kan ik zelf niet achterhalen.

Antivirus is een goede, daar hebben we in het verleden bij andere klanten ook al problemen mee gehad. Voor zover ik weet zijn momenteel alle paden die we (dachten) gebruikt te worden door de software al excluded. Maarja met de huidige stand van zaken ga ik hun IT Partner toch maar eens vragen of ze me kunnen vertellen of er misschien alsnog een scanner loopt, maar dan wellicht op een of ander temp path ofzo.

Client heeft in elk geval geen virusscanner.

[De_Bastaard]

Toch maar even een klein kickje van mijn kant :-)

De klant is er inmiddels met hun IT partner achter gekomen dat op het moment van het 'opslaan' van een e-mail in het Document management systeem, er een query wordt uitgevoerd op SQL.

Nu duurt deze query maar 4 á 5 seconden (wat voor een query niet lang is), maar als de client daarop moet wachten is het wel lang.

Erg apart, want onze andere klanten die met meer gebruikers, documenten, locaties e.d. werken hebben hier geen last van.

De bottleneck lijkt so far in elk geval wel de SQL Server te zijn, want als ik de query direct uitvoer op de SQL Server duurt het ook 4 á 5 seconden voordat deze klaar is.

Ik denk dat de server te weinig RAM heeft (momenteel 8gb), maar daar ben ik nog niet helemaal over uit.

[Wim-Bart]

De_Bastaard schreef op maandag 23 april 2012 @ 19:46:
Als het goed is draaien de clients geen virusscanner, de servers al helemaal niet.

Dat kan al een teken zijn dat er dingen fout kunnen gaan. Foei.