50 votos

Windows Escala de Ventana de TCP Golpear meseta demasiado temprano

Escenario: Tenemos un número de clientes de Windows con regularidad la carga de archivos grandes (FTP/SVN/HTTP PUT/SCP) para servidores Linux que son ~100-160ms de distancia. Hemos de 1Gbit/s síncrona de ancho de banda en la oficina y los servidores son instancias de AWS o físicamente alojados en NOSOTROS DCs.

El informe inicial fue que sube a una nueva instancia de servidor eran mucho más lentos de lo que podrían ser. Este orificio de salida en la prueba y de localizaciones múltiples, los clientes estaban viendo estable 2-5Mbit/s para el host de sus sistemas Windows.

Estalló iperf -s en una instancia de AWS y, a continuación, a partir de un Windows cliente en la oficina:

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

La última cifra puede variar significativamente en las pruebas posteriores, (Caprichos de la AWS), pero suele ser entre 70 y 130Mbit/s, que es más que suficiente para nuestras necesidades. Uso de wireshark con la sesión, puedo ver:

  • iperf -c Windows SYN - Ventana de 64kb, Escala 1 - Linux SYN, ACK: Ventana de 14kb, Escala: 9 (*512) iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN - Windows de 64 kb, Escala 1 - Linux SYN, ACK: Ventana de 14kb, Escala: 9 iperf window scaling with default 1MB Window

Claramente el vínculo puede mantener este alto rendimiento, pero tengo que expresamente establece el tamaño de la ventana para hacer uso de ella, que la mayoría de las aplicaciones del mundo real no me deja hacer. El TCP apretones de mano se utilizan los mismos puntos de partida en cada caso, pero la forzada escalas

Por el contrario, desde un cliente Linux en la misma red recta, iperf -c (utilizando el sistema por defecto 85kb) me da:

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

Sin forzar, como las escalas de espera. Esto no puede ser algo en el transcurso de los saltos o con uno de nuestros switches/routers y parece afectar a Windows 7 y 8 clientes por igual. He leído un montón de guías en el auto-ajuste, pero estos suelen ser acerca de cómo desactivar el escalado por completo para evitar el mal terrible home kit de red.

¿Alguien puede decirme qué está pasando aquí y me dan una manera de arreglarlo? (De preferencia algo que puede pegarse en el registro a través de GPO.)

Notas

La AWS instancia de Linux en cuestión tiene las siguientes opciones del núcleo aplicado en sysctl.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

He usado dd if=/dev/zero | nc redireccionar /dev/null en el servidor para descartar iperf y eliminar otras posibles cuellos de botella, pero los resultados son prácticamente los mismos. Pruebas con ncftp (Cygwin, Nativo de Windows, Linux) escala en mucho la misma manera que el anterior iperf pruebas en sus respectivas plataformas.

Editar

He detectado otro consistente cosa en la que puede ser relevante: enter image description here

Este es el primer segundo de la 1MB de captura, la imagen ampliada. Usted puede ver de Inicio Lento de la acción, como la ventana de escalas y el buffer se hace más grande. Hay entonces esta pequeña meseta de ~0.2 s exactamente en el punto en el que el valor predeterminado de la ventana de iperf prueba se aplana para siempre. Este curso de escalas mucho dizzier alturas, pero es curioso que hay una pausa en la escala (Valores son 1022bytes * 512 = 523264) antes de que se lo hace.

Actualización 30 de junio.

El seguimiento de las distintas respuestas:

  • La habilitación de CTCP - Esto no hace ninguna diferencia; el escalado de la ventana es idéntica. (Si lo entiendo correctamente, este valor aumenta la velocidad a la que la ventana de congestión se agranda más que el tamaño máximo que puede alcanzar)
  • Habilitar TCP marcas de tiempo. - No cambio por aquí.
  • El algoritmo de Nagle - que tiene sentido y Que al menos significa que probablemente puede ignorar que en particular picos en la gráfica como cualquier indicación del problema.
  • pcap archivos: archivo Zip disponible aquí: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anónima con bittwiste, se extrae ~150MB como hay uno de cada sistema operativo de cliente para la comparación)

Actualización 2 - 30 de junio

O, por lo que después de op en Kyle sugerencia, he habilitado el ctcp y movilidad de la chimenea de descarga: TCP Parámetros Globales

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

Pero, lamentablemente, no hay cambio en el rendimiento.

Tengo una causa/efecto de la pregunta, sin embargo: Los gráficos son de la RWIN valor configurado en el servidor del Ack para el cliente. Con los clientes de Windows, estoy en lo cierto al pensar que Linux no es el escalado de este valor, más allá de que su punto más bajo debido a que el cliente es limitada CWIN impide incluso que el buffer se llene? Puede haber alguna otra razón que Linux es limitar artificialmente el RWIN?

Nota: he intentado encender ECN para el infierno; pero no hay cambio, no.

Actualización 3 de junio 31.

Ningún cambio después de la desactivación de la heurística y RWIN de autoajuste. Se han actualizado los de Intel de la red de controladores a la última (12.10.28.0) con el software que expone functioanlity ajustes viadevice administrador de pestañas. La tarjeta es una 82579V Chipset de la placa de NIC - (voy a hacer algunas pruebas más de los clientes con realtek o de otros proveedores)

Centrándose en la NIC por un momento, he intentado lo siguiente (más que nada por descartar raro culpables):

  • Aumento de búferes de recepción a 2k de 256 y búferes de transmisión a 2k de 512 (Ambos ahora en el máximo): Sin cambio
  • Desactivado todos los IP/TCP/UDP descarga de suma de comprobación. - Ningún cambio.
  • Deshabilitado La Descarga De Envío Grande - Nada.
  • Apagado IPv6, QoS programación - Nowt.

Actualización 3 - 3 de julio

Tratando de eliminar el servidor Linux lado, comencé a subir un Server 2012R2 instancia y repite las pruebas mediante iperf (cygwin binario) y NTttcp.

Con iperf, tuve que especificar explícitamente -w1m en ambos lados antes de la conexión de la escala más allá de ~5Mbit/s. (Por cierto, yo podría ser revisado y la BDP de ~5Mbits en 91ms latencia es casi con precisión de 64 kb. Spot el límite...)

El ntttcp binarios mostró ahora tal limitación. El uso de ntttcpr -m 1,0,1.2.3.5 en el servidor y ntttcp -s -m 1,0,1.2.3.5 -t 10 sobre el cliente, puedo ver mucho mejor rendimiento:

Copyright Version 5.28
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8MB/s lo pone hasta en los niveles en los que estaba recibiendo con explícitamente grandes ventanas en iperf. Curiosamente, a pesar de que, 80MB en 1273 buffers = un búfer de 64 kb de nuevo. Una más wireshark muestra, variable RWIN viniendo desde el servidor (factor de Escala de 256) que el cliente parece cumplir; así que tal vez ntttcp está falseando la ventana de envío.

Actualización 4 - 3 de julio

En @karyhead petición, he hecho algunas pruebas más y generado un poco más capturas, aquí: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

  • Dos más iperfs, tanto de Windows al mismo servidor Linux como antes (1.2.3.4): Uno con un 128k Socket predeterminada y de tamaño de 64 kb de la ventana (restringe a ~5Mbit/s de nuevo) y uno con un 1MB ventana de envío y predeterminado de 8 kb de tamaño de socket. (escalas mayores)
  • Uno ntttcp de seguimiento desde el mismo cliente de Windows a un Server 2012R2 instancia de EC2 (1.2.3.5). aquí, el rendimiento de las escalas. Nota: NTttcp hace algo extraño en el puerto 6001 antes de que se abra la conexión de la prueba. No estoy seguro de lo que está pasando ahí.
  • Uno de los datos FTP de seguimiento, la carga de 20MB de /dev/urandom a cerca de un idéntico host de linux (1.2.3.6) usando Cygwin ncftp. De nuevo, el límite es de allí. El patrón es casi el mismo de Windows utilizando Filezilla.

El cambio de la iperf la longitud del búfer hace la diferencia esperada para el tiempo de la secuencia gráfica (mucho más secciones verticales), pero el rendimiento real es invariable.

15voto

Pat Puntos 1087

Has intentado habilitar TCP Compuesto (CTCP) en su Windows 7/8 clientes.

Por favor lea:

El aumento de Remitente Rendimiento de Alta Transmisión de BDP

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

Estos algoritmos funcionan bien para las pequeñas Bdp y los más pequeños de la ventana de recepción los tamaños. Sin embargo, cuando usted tiene una conexión TCP con un gran reciben el tamaño de la ventana y un gran BDP, tales como la replicación de datos entre dos los servidores que se encuentra a través de una alta velocidad de enlace WAN con un 100ms de ida el tiempo, estos algoritmos no aumente la ventana de envío bastante rápido para utilizar completamente el ancho de banda de la conexión.

Para aprovechar mejor el ancho de banda de las conexiones TCP en estos situaciones, la Próxima Generación de la pila TCP/IP incluye TCP Compuesto (CTCP). CTCP de forma más agresiva aumenta la ventana de envío de conexiones con grandes tamaños de ventana de recepción y Bdp. CTCP intenta maximizar el rendimiento de estos tipos de conexiones mediante el monitoreo de retraso las variaciones y pérdidas. Además, el CTCP se asegura de que su comportamiento no afecta negativamente a otras conexiones TCP.

...

CTCP está habilitado de forma predeterminada en los equipos que ejecutan Windows Server 2008 y movilidad por por defecto en los equipos que ejecutan Windows Vista. Puede habilitar el CTCP con la netsh interface tcp set global congestionprovider=ctcp comando. Puede deshabilitar CTCP con el netsh interface tcp set global congestionprovider=none comando.

Editar 6/30/2014

a ver si CTCP está realmente "en"

> netsh int tcp show global

es decir,

enter image description here

PO dijo:

Si lo entiendo correctamente, esta configuración aumenta la velocidad a la que la ventana de congestión se agranda más que el tamaño máximo se puede llegar a

CTCP agresiva aumenta la ventana de envío

http://technet.microsoft.com/en-us/library/bb878127.aspx

TCP compuesto

Los algoritmos existentes que impiden que un envío de TCP pares de abrumadora la red se conoce como inicio lento y la congestión la evitación. Estos algoritmos de aumentar la cantidad de segmentos que el el remitente puede enviar, conocida como la ventana de envío, cuando inicialmente el envío de datos en la conexión y cuando se está recuperando de un segmento perdido. Inicio lento aumenta la ventana de envío por un segmento TCP completo por cada reconocimiento segmento recibido (para TCP en Windows XP y Windows Server 2003) o para cada segmento de reconocida (para TCP en Windows Vista y Windows Server 2008). Para evitar la congestión aumenta la ventana de envío por un segmento TCP completo para cada ventana de datos completa que es reconocido.

Estos algoritmos funcionan bien para LAN las velocidades de los medios y de menor tamaño de la ventana TCP los tamaños. Sin embargo, cuando usted tiene una conexión TCP con un gran reciben el tamaño de la ventana y un gran ancho de banda-retardo del producto (ancho de banda alto y alto retardo), tales como la replicación de datos entre dos servidores ubicados a través de una WAN de alta velocidad con un vínculo de 100 ms tiempo de ida y vuelta, estos los algoritmos de no aumentar la ventana de envío bastante rápido para totalmente utilizar el ancho de banda de la conexión. Por ejemplo, en un 1 Gigabit por segundo (Gbps) enlace WAN con un 100 ms tiempo de ida y vuelta (RTT), se puede tomar hasta una hora para que la ventana de envío inicialmente para aumentar la gran tamaño de la ventana que se anuncia por el receptor y recuperar al hay segmentos perdidos.

Para aprovechar mejor el ancho de banda de las conexiones TCP en estos situaciones, la Próxima Generación de la pila TCP/IP incluye TCP Compuesto (CTCP). CTCP de forma más agresiva aumenta la ventana de envío de conexiones con grandes tamaños de ventana de recepción y gran ancho de banda-retardo productos. CTCP intenta maximizar el rendimiento de estos tipos de las conexiones de monitoreo de las variaciones de retraso y pérdidas. CTCP también se asegura de que su comportamiento no afecta negativamente a otras TCP las conexiones.

En las pruebas realizadas internamente en Microsoft, gran copia de seguridad de archivos veces se redujeron casi a la mitad por una conexión de 1 Gbps con un 50ms RTT. Conexiones con un mayor ancho de banda retardo producto puede tener incluso mejor rendimiento. CTCP y Recibir ajuste Automático de Ventana de trabajar juntos para el aumento de la utilización del acoplamiento y pueden resultar en importantes rendimiento las ganancias de ancho de banda-retardo del producto conexiones.

12voto

Kyle Brandt Puntos 50907

Aclarar el Problema:

TCP tiene dos ventanas:

  • La ventana de recepción: ¿cuántos bytes quedan en el buffer. Este es el flujo de control impuestas por el receptor. Usted puede ver el tamaño de la ventana de recepción en el wireshark, ya que se compone de el tamaño de la ventana y el cerramiento del factor de escala en el interior de la cabecera TCP. Ambos lados de la conexión TCP se anuncian su ventana de recepción, pero en general la que importa es la persona que recibe el grueso de los datos. En su caso, es el "servidor" ya que el cliente es la carga en el servidor
  • La ventana de congestión. Este es el flujo de control impuestas por el Remitente. Este es mantenida por el sistema operativo y no se muestra en el encabezado TCP. Controla la tasa de cómo de rápido se envían datos.

En el archivo de captura proporcionada. Podemos ver que el búfer de recepción nunca es desbordante:

enter image description here

Mi análisis es que el remitente no se envío rápido porque la ventana de envío (también conocido como el control de la congestión de la ventana) no es la apertura suficiente para satisfacer el RWIN del receptor. Así que en breve el receptor dice "dame Más", y cuando Windows es el remitente no es el envío bastante rápido.

Esto se evidencia por el hecho de que en la gráfica anterior, el RWIN permanece abierto, y con el tiempo de ida y vuelta de .09 segundos y un RWIN de de ~ 500.000 bytes, podemos esperar un máximo rendimiento de acuerdo con el ancho de banda retardo de producto(500000/0.09) * 8 =~ 42 Mbit/s (y usted está consiguiendo solamente acerca de ~5 en su win a Linux en la captura).

Cómo solucionarlo?

No sé. interface tcp set global congestionprovider=ctcp suena como la cosa correcta de hacer para mí, porque aumentaría la ventana de envío (que es otro término para la ventana de congestión). Usted dijo que no está funcionando. Sólo para asegurarse de que:

  1. ¿Reiniciar después de habilitar esta función?
  2. Es la Chimenea de descarga? Si es que tal vez intente desactivarlo como un experimento. No sé exactamente lo que pone de descarga cuando esta habilitado, pero si el control de la ventana de envío es uno de ellos, tal vez congestionprovider no tiene ningún efecto cuando esta opción está habilitada... solo estoy adivinando...
  3. Yo también creo que esto puede ser anterior a windows 7, pero usted puede tratar de añadir y jugando con las dos claves del registro llamado DefaultSendWindow y DefaultReceiveWindow en HKEY_LOCAL_MACHINE-System-CurrentControlSet-Servicios-AFD-Parámetros. Si estas incluso el trabajo, usted probablemente bid se han ctcp off.
  4. Otra conjetura, intente comprobar netsh interface tcp show heuristics. Creo que podría ser RWIN, pero no lo dice, así que tal vez jugar con la deshabilitación/habilitación de que en caso de que los impactos de la ventana de envío.
  5. También, asegúrese de que los controladores están actualizados en tu cliente de prueba. Tal vez es algo que sólo roto.

Me gustaría probar todos estos experimentos con todo lo que la descarga de las características off para empezar a eliminar la posibilidad de que los controladores de red están haciendo algunos reescritura/modificación de las cosas (mantenga un ojo de la CPU, mientras que la descarga está deshabilitado). El TCP_OFFLOAD_STATE_DELEGATED struct parece, al menos, implica que CWnd la descarga es al menos posible.

5voto

karyhead Puntos 156

Ha habido algunos grandes info aquí por @Pat y @Kyle. Definitivamente la atención de la paga a @Kyle explicación de la TCP recibir y enviar de windows, creo que ha habido cierta confusión en torno a eso. Para confundir más, iperf se utiliza el término "de la ventana de TCP" con el -w que es un término ambiguo con respecto a la recepción, envío, o en general de la ventana deslizante. Lo que realmente hace es fijar el zócalo en el buffer de envío de la -c (cliente) de la instancia y el zócalo búfer de recepción en la -s (servidor) de la instancia. En src/tcp_window_size.c:

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

Como Kyle menciona, el problema no es con la ventana de recepción en el cuadro de Linux, pero el remitente no es la apertura de la ventana de envío suficiente. No es que no abre hasta bastante rápido, sólo las tapas en los 64 kb.

El socket predeterminado de tamaño de búfer en Windows 7 es de 64 kb. He aquí lo que la documentación dice sobre el socket tamaño de búfer en relación con el rendimiento en MSDN

Cuando el envío de datos a través de una conexión TCP utilizando sockets de Windows, es importante para mantener una cantidad suficiente de datos pendientes (enviado pero no se reconoce todavía) en TCP con el fin de lograr el más alto rendimiento. El valor ideal para la cantidad de datos pendientes a lograr el mejor rendimiento de la conexión TCP se llama el ideal enviar retraso (ISB) de tamaño. El ISB de valor es una función de la ancho de banda-retardo producto de la conexión de TCP y el receptor del anuncian la ventana de recepción (y, en parte, la cantidad de congestión en el de la red).

Ok, bla, bla, bla, Ahora, aquí vamos:

Las aplicaciones que realizan un bloqueo o sin bloqueo de enviar la solicitud en un tiempo, en general, dependen interno enviar búfer de Winsock para lograr decente rendimiento. El búfer de envío límite para una conexión dada es controlado por el SO_SNDBUF opción de socket. Para el bloqueo y sin bloqueo método de envío, el búfer de envío de límite determina cuánto los datos se mantienen pendientes en TCP. Si el ISB valor para la conexión es más grande que el búfer de envío de límite, entonces el rendimiento alcanzado en la conexión no será el óptimo.

El promedio de rendimiento de su más reciente iperf prueba con el de 64 kb de la ventana es de 5.8 Mbps. Que a partir de las Estadísticas > Resumen en Wireshark, que cuenta con todos los bits. Probablemente, iperf es contar TCP rendimiento de datos que es de 5,7 Mbps. Vemos el mismo rendimiento que con la prueba de FTP así, ~5.6 Mbps.

El teórico y el rendimiento con un 64 kb en el buffer de envío y 91ms RTT es....5.5 Mbps. Lo suficientemente cerca como para mí.

Si nos fijamos en su 1MB ventana iperf de la prueba, el tput es 88.2 Mbps (86.2 Mbps por solo datos TCP). El teórico tput con un 1MB ventana es un 87,9 Mbps. De nuevo, lo suficientemente cerca para que el trabajo del gobierno.

Esto lo que demuestra es que el socket de envío buffer directamente los controles de la ventana de envío y que, junto con la de la ventana de recepción desde el otro lado, los controles de rendimiento. La publicidad de la ventana de recepción de habitación, por lo que no estamos limitados por el receptor.

Aguantar, lo que acerca de este autoajuste de negocio? No Windows 7 que manejar las cosas de forma automática? Como se ha mencionado, Windows no manejar auto-escalado de la ventana de recepción, pero también puede manejar dinámicamente el buffer de envío. Volvamos a la página de MSDN:

Dinámica de enviar el almacenamiento en búfer para TCP fue agregado en Windows 7 y Windows Server 2008 R2. De forma predeterminada, la dinámica de enviar el almacenamiento en búfer para TCP está habilitado a menos que una aplicación establece la SO_SNDBUF opción de socket en el arroyo zócalo.

iperf utiliza SO_SNDBUF cuando se usa el -w opción, tan dinámico enviar el almacenamiento en búfer será desactivada. Sin embargo, si usted no usa -w entonces no uso SO_SNDBUF. Dinámica de enviar el almacenamiento en búfer debe ser activada por defecto, pero se puede comprobar:

netsh winsock show autotuning

La documentación dice que se puede desactivar con:

netsh winsock set autotuning off

Pero eso no funciona para mí. He tenido que hacer un cambio de registro y establecer a 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

No creo que la desactivación de esto va a ayudar; es simplemente una FYI.

¿Por qué no su búfer de envío de escala por encima de los 64 kb predeterminado cuando el envío de datos a un cuadro de Linux con un montón de espacio en la ventana de recepción? Gran pregunta. Kernel de Linux también tienen un autoajuste pila TCP. Como T-pain y Kanye haciendo un autotune dueto juntos, es posible que no suena bien. Tal vez hay algún problema con los dos autoajuste de pilas TCP hablando el uno al otro.

Otra persona ha tenido un problema como el suyo y fue capaz de solucionarlo con una edición de registro para aumentar el valor predeterminado tamaño de búfer de envío. Por desgracia, eso no parece funcionar, al menos no para mí cuando me lo probé.

En este punto, creo que es claro que el factor limitante es el tamaño de búfer de envío en el host de Windows. Dado que no parece ser dinámicamente creciendo adecuadamente, ¿qué es una muchacha a hacer?

Usted puede:

  • El uso de aplicaciones que permiten establecer el búfer de envío decir, la opción de la ventana
  • El uso de un local de Linux proxy
  • Uso remoto del servidor proxy de Windows?
  • Abrir un caso con Microsofhahahahahahaha
  • La cerveza

Descargo de responsabilidad: he pasado muchas horas investigando este y es correcta al mejor de mi conocimiento y mi google-fu. Pero no os lo juro por la tumba de mi madre (ella aún vive).

4voto

Leslie Murphy Puntos 11

Una vez que la pila TCP atentos, usted todavía puede tener un cuello de botella en la capa de Winsock. He encontrado que la configuración de Winsock (Controlador de Función Auxiliar en el registro) hace una gran diferencia en la velocidad de carga (empujando los datos en el servidor) en Windows 7. Microsoft ha reconocido un error en el ajuste automático TCP para sockets de bloqueo -- justo el tipo de socket que los navegadores de uso ;-)

Agregar clave DWORD para DefaultSendWindow y establezca la BDP o superior. Estoy usando 256000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

Cambio de la configuración de Winsock para descargas podría ayudar - añadir una clave para DefaultReceiveWindow.

Usted puede experimentar con diferentes nivel de socket de la configuración mediante el Violinista Proxy y comandos para ajustar el cliente y el servidor de socket tamaños de búfer:

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF

0voto

Bien, me he encontrado con una situación similar a mí mismo (mi pregunta aquí), y al final he tenido que deshabilitar TCP escala heurística, establezca manualmente el autoajuste de perfil y habilitar CTCP:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok. 

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: