Wir sehen ein bizarres und unerklärliches Phänomen mit ZeroMQ auf Windows 7, Senden von Nachrichten über TCP. (Oder über inproc, da ZeroMQ TCP intern für Signalisierung unter Windows verwendet).Warum nimmt TCP/IP unter Windows7 500 Sends zum Aufwärmen? (w10, w8 erwies sich nicht zu leiden)
Das Phänomen ist, dass die ersten 500 Nachrichten immer langsamer ankommen und die Latenz stetig steigt. Dann sinkt die Latenz, und Nachrichten kommen konsistent schnell an, mit Ausnahme von Spitzen, die durch CPU-/Netzwerkkonflikte verursacht werden.
Die Frage ist hier beschrieben: https://github.com/zeromq/libzmq/issues/1608
Es konsequent 500 Meldungen ist. Wenn wir ohne Verzögerung senden, werden die Nachrichten in einem Stapel zusammengefasst, so dass wir sehen, dass sich das Phänomen über mehrere tausend Sends erstreckt. Wenn wir zwischen Sends verzögern, sehen wir den Graphen klarer. Selbst Verzögerungen von bis zu 50-100 ms zwischen Sends ändern nichts.
Die Größe der Nachricht ist ebenfalls irrelevant. Ich habe mit 10-Byte-Nachrichten und 10K-Nachrichten mit den gleichen Ergebnissen getestet.
Die maximale Latenz beträgt immer 2 ms (2.000 usec).
Auf Linux-Boxen sehen wir dieses Phänomen nicht.
Wir möchten diese Anfangskurve eliminieren, so dass Nachrichten mit ihrer normalen niedrigen Latenzzeit (etwa 20-100 Usec) eine neue Verbindung eingehen.
Update: das Problem nicht auf Windows nicht zeigen 10 noch 8. Es scheint nur auf Windows passieren.
Wild hunch: Ich frage mich, ob dies mit TCP-Autotuning in Win7 verwandt werden könnte: http://www.sevenforums.com/network-sharing/74556-enable-disable-tcp-auto-tuning.html – keithmo
Großartig Vorsichtige, wir überprüfen es. Stellt sich heraus, das Phänomen scheint nicht auf Windows 10, weder Windows 8 passieren. So könnte es in der Tat eine Windows 7 Autotuning-Funktion sein. –