Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Nota:
Este artículo se incluye en una serie de tres partes. Puede revisar la parte 2: Problemas conocidos de rendimiento de TCP/IP subyacentes y Parte 3: Problemas conocidos de rendimiento de TCP/IP.
El rendimiento del Protocolo de control de transmisión/Protocolo de Internet (TCP/IP) es una comparación. La comparación debe realizarse con puntos de conexión idénticos en términos de hardware, ruta de acceso de red y sistema operativo. El rendimiento real es diferente porque hay varios factores involucrados y podrían producir un cuello de botella. Estos factores suelen ser los siguientes: la red subyacente, el diseño de TCP y la velocidad de transmisión real de las E/S de almacenamiento.
Obtenga más información sobre el ajuste del rendimiento para establecer la configuración de mejor rendimiento para los puntos de conexión.
El ajuste automático de ventanas de recepción TCP es una característica definida por la aplicación que se usa para escalar verticalmente la conexión para usar el ancho de banda en redes de alta latencia. Por ejemplo, si el TCP está configurado para usar el nivel de ajuste automático a la normalidad y si la aplicación tiene el búfer suficiente definido para la ventana TCP, el sistema operativo escalará el TCP para que sea máximo rápidamente. Sin embargo, esta característica está diseñada para redes de mayor latencia. En el caso de las redes de baja latencia, no hay ningún requisito, ya que no habrá muchos segmentos sobre la marcha (por ejemplo, en la infraestructura de red).
Para las redes de alta latencia con una ventana TCP que no se escala hasta el máximo a la vez, hay algoritmos como CUBIC, NewReno y Compound TCP para determinar el producto de retraso de ancho de banda (BDP) y escalar la ventana en consecuencia. El sistema operativo Windows asigna un algoritmo de congestión a cada socket creado.
La configuración de TCP está predefinida en Windows 10. Use el cmdlet Get-NetTCPSettings para obtener la configuración de TCP y use el cmdlet Get-NetTCPConnection para ver las propiedades de conexión TCP, como la dirección IP local o remota, el puerto local o remoto y el estado de conexión.
Estas son las sugerencias para mejorar el rendimiento:
- Asegúrese de que no hay ningún problema de red subyacente (pérdida de paquetes).
- Habilite las propiedades avanzadas de NIC de las características de rendimiento (por ejemplo, tramas gigantes, RSS/VMQ, características de descarga y RSC), excepto si hay un problema de compatibilidad de red subyacente o para solucionar problemas.
- Asegúrese de que el TCP está configurado para usar el nivel de ajuste automático en su valor normal.
- Use el análisis de Monitor de rendimiento para asegurarse de que no haya cuellos de botella en la CPU ni en el almacenamiento.
- Seleccione características de seguridad que se basen en los requisitos reales de las organizaciones.
- Cree una línea de base.
Herramienta de prueba para el rendimiento de TCP
Para lograr el mayor rendimiento posible para un determinado hardware, debe ajustar los factores de rendimiento. Asegúrese de que no haya ningún problema de red subyacente (pérdida de paquetes). Use la herramienta NTttcp.exe o ctsTraffic.exe para probar el rendimiento. Consulte Herramientas de rendimiento para cargas de trabajo de red.
Cuellos de botella para el rendimiento de TCP
No use el monitor de red ni tome registros de nivel de paquete de red durante las pruebas de rendimiento tcp. Los filtros de supervisión de la especificación de interfaz de controlador de red (NDIS) agregan un retraso para el remitente y los receptores cada vez que se registra un paquete. Esta operación exige recursos de CPU y genera muchas E/S de almacenamiento. El rendimiento disminuye cuando se toman registros de nivel de paquete porque TCP intenta recuperarse de la pérdida de paquetes.
Agregar seguridad tiene sus propios problemas de costo y rendimiento. Los protocolos de seguridad como Internet Protocol Security (IPsec) tienen requisitos de sobrecarga y procesamiento adicionales. En comparación con la protección de datos con integridad de datos, se debe preferir el modo de integridad de IPsec para un menor costo de procesamiento. El software de seguridad también tiene un gran costo en el procesamiento de paquetes, lo que provocará salidas más lentas.
Si el rendimiento probado no llega a las expectativas, tome los registros como se define en Contadores de rendimiento relacionados con la red.
Después de comprobar si hay problemas de rendimiento de TCP, compruebe los protocolos asociados de nivel superior, como los protocolos del sistema de archivos (bloque de mensajes del servidor (SMB) o el sistema de archivos de red (NFS)). Estos protocolos requieren recursos de procesador y E/S de disco. La velocidad lenta se debe a un controlador o hardware defectuosos, una cola de llamada a procedimiento diferido (DPC) o E/S de disco lento. Averiguar qué componente del sistema operativo está causando un alto número de DPC es difícil porque eso requiere un análisis mediante el registro de Xperf/Windows Performance Recorder (WPR) (CPU). Encontrar problemas de lentitud relacionados con el disco es comparativamente más fácil. Para obtener más información, consulte Examen y optimización del rendimiento del disco.
Durante la prueba, las aplicaciones de prueba (aplicaciones cliente y de servidor) se pueden ajustar para usar varios subprocesos con valores de búfer lo suficientemente altos como para alcanzar el rendimiento máximo. Sin embargo, esto podría no reflejar las condiciones reales porque el número de subprocesos y el búfer que puede utilizar cada llamada API se limita en función de la programación. Además, el protocolo de capa de aplicación (SMB o Common Internet File System (CIFS)) tiene su propio búfer y optimización (Optimización del rendimiento para servidores de archivos o SMB: Guía de solución de problemas). Si la aplicación no funciona según lo previsto para la línea base, trabaje con un especialista en aplicaciones para encontrar el cuello de botella.
Creación de una línea base
Se debe crear una línea base de rendimiento para comparar el rendimiento actual. Para comprender mejor la red, cree la línea base al principio de la implementación.
Una línea base está formada por los siguientes puntos principales:
- Redes de origen y destino
- Recuento de latencia y saltos entre estas redes
- Funcionalidad y configuración de procesador/interfaz
- Período de tiempo de las pruebas (horas de trabajo/horas no laborables/horas punta)
- Versiones del SO
- Extracción de rendimiento e inserción de rendimiento
Nota:
Cree la línea base con los mismos modelos de servidor (el mismo número de tarjetas NIC y capacidad de procesador) para mantener la potencia de procesamiento casi igual.
Observe el búfer y realice un seguimiento del número de sesiones de transporte creadas por las herramientas de prueba. Cuatro sesiones de transporte TCP simultáneas pueden evaluarse mediante cpu uniformemente con RSS habilitado.
Estos son los pasos para medir el rendimiento y crear una línea base:
Descargue la herramienta ctsTraffic . Esta es una descripción de algunos parámetros de la herramienta ctsTraffic.
Parámetro Descripción -listen:<IP/*>
Esta opción se usa para la escucha de puertos en servidores. Si *
se especifica, la herramienta ctsTraffic escucha todas las direcciones IP disponibles en ese equipo. Por ejemplo,-listen:*
.-target:<IP>
Esta opción se usa en los clientes y especifica la dirección IP del servidor en el que se ejecuta ctsTraffic.exe y está en estado de escucha. Por ejemplo, -target:192.168.1.10
.-pattern:pull
La herramienta CtsTraffic usa el patrón Push de forma predeterminada. Esto significa que los datos se envían desde el cliente al servidor. Cuando se usa este modificador tanto en el cliente como en el servidor, los datos se reciben en el cliente. No use esta opción al realizar una prueba de inserción. -connections:<num>
Esta opción especifica el número de conexiones TCP. Los sockets TCP se crearán a partir del cliente simultáneamente. Ocho se usan normalmente como colas RSS en tarjetas de red de nivel medio son 8. Por ejemplo, -connections:8
.-iterations:<num>
Esta opción especifica el número multiplicado de conexiones en -connections:
. Por ejemplo,-iterations:10
. Con 10 iteraciones, el cliente intentará 80 conexiones en total. Si no se especifica esta opción, el cliente seguirá intentando 8 conexiones hasta 1000 conexiones.-statusfilename:<filename.csc>
Use esta opción para vaciar la opción de nivel de consola 1 a un .txt
archivo compatible con Microsoft Excel.-connectionfilename:<filename.csv>
Use esta opción para vaciar los detalles detallados. Por ejemplo, información de nivel de socket, como el tiempo que tarda cada socket en transferir los datos. Puede comprobar si hay algún error o solución de problemas avanzada con esta opción. -consoleverbosity:<0|1|2|3>
Esta opción especifica la vista o la salida en el monitor mientras se ejecuta la prueba. Por ejemplo, -consoleverbosity:1
.Abra Resource Monitor en el lado receptor. Por ejemplo, si usa
-pattern:pull
, ábralo en el cliente; de lo contrario, ábralo en el servidor.Inicie la herramienta ctsTraffic en el servidor y ejecute el siguiente comando:
Ctstraffic.exe -listen:* -consoleverbosity:1 <-pattern:pull>
Inicie la herramienta ctsTraffic en el cliente y ejecute el siguiente comando:
Ctstraffic.exe -target:<serverip> -consoleverbosity:1 <-pattern:pull> -connections:8 -iterations:10
Asegúrese de que los procesadores del lado receptor se usan uniformemente. Si no lo son, compruebe el problema con RSS para averiguar cuál no funciona según lo previsto.
Calcule el rendimiento en bits/segundo según el resultado en el cliente. Consulte el ejemplo en la captura de pantalla siguiente:
En este ejemplo, el rendimiento es de casi 19 Gb/s y se calcula de la siguiente manera:
(85,899,349,200 bytes/36,678 segundos) * 8 = 18,735,885,097,33355 (bits/segundo)