Rozmiary okien TCP

www.wp.pl 4380
www.onet.pl 5792
www.google.pl 5672
www.gazeta.pl 32768
www.microsoft.com 8190

Jak uaktywnia się skalowanie okna TCP

W przypadku Axis-a można to rozwiązać tak:

System.setProperty("tcp.window.size", "64000");
AxisProperties.setProperty("axis.socketFactory", "CustomSocketFactory");

Czasy WebService'u dla rozmiaru okna:

1460 (RWIN=MSS :) => 21860 ms
5000, 7000, 17000, 33000, 64000 => 4500-6500 ms

TCP Window Scaling

Diagnostyka i konfiguracja. Po drodze może być stary Cisco IOS Firewall obcinający pakiety spoza okna (którego rozmiar jest w rzeczywistości przeskalowany przez 2^wscale)...

Tweakowanie systemu Windows

... na podstawie oryginalnej dokumentacji od MS.

Prstat

27109 adinstan  469M  323M cpu1    30    0 209:37:17  35% bwengine/64
27109 adinstan  469M  323M cpu17   20    0 209:37:45  35% bwengine/64
27109 adinstan  469M  323M cpu16   20    0 209:38:14  35% bwengine/64
27109 adinstan  469M  323M cpu17   20    0 209:38:56  35% bwengine/64
27109 adinstan  469M  323M cpu18   20    0 209:39:10  35% bwengine/64
27109 adinstan  469M  323M cpu0    10    0 209:39:24  35% bwengine/64
27109 adinstan  469M  323M cpu2    10    0 209:39:38  35% bwengine/64
27109 adinstan  469M  323M cpu19   10    0 209:40:07  35% bwengine/64

Proces skacze po procesorach. Można go dowiązać narzędziami psrset+pbind, co powinno zmniejszyć opóźnienia (ważna rzecz dla np. aplikacji RT).

Yet another firewall issue

Pod koniec wywołania WebService'u ginie segment TCP; warstwa transportowa ciągle próbuje dokończyć transmisję, co widać jako wiszenie WebService'u. Co ciekawe, w takim przypadku w kliencie .NET ustawienie timeout-u nic nie daje i aplikacja kliencka będzie cała wisieć.

W trybie debugowania pojawia się ContextSwitchDeadlockException: The CLR has been unable to transition from COM context 0x21def80 to COM context 0x21df1d0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.
netsh int tcp set global autotuninglevel=disabled
DefaultTTL=128, SackOpts=0

Software'owy RAID w W2K8

Mirror partycji systemowej możemy stworzyć paroma kliknięciami bez restartu. Do boot menu dodana zostanie pozycja umożliwiająca odpalenie systemu z drugiego dysku. Wszystko dużo łatwiejsze i szybsze niż w Linuksie i Solarisie. Mój ulubiony layout: RAID1 + RAID0.