La versión de línea de base: una aplicación con un rendimiento muy deficiente
El ejemplo de código inicial y con un rendimiento deficiente que se usa para calcular las actualizaciones es el siguiente:
Nota
Por motivos de simplicidad, no hay ningún control de errores en los ejemplos siguientes. Cualquier aplicación de producción siempre comprueba los valores devueltos.
Advertencia
Los primeros ejemplos de la aplicación proporcionan un rendimiento intencionadomente deficiente, con el fin de ilustrar las mejoras de rendimiento posibles con los cambios en el código. No use estos ejemplos de código en la aplicación; son solo para fines ilustrativos.
#include <windows.h>
BOOL Map[ROWS][COLS];
void LifeUpdate()
{
ComputeNext( Map );
for( int i = 0 ; i < ROWS ; ++i ) //serialized
for( int j = 0 ; j < COLS ; ++j )
Set( i, j, Map[i][j] ); //chatty
}
BYTE Set(row, col, bAlive)
{
SOCKET s = socket(...);
BYTE byRet = 0;
setsockopt( s, SO_SNDBUF, &Zero, sizeof(int) );
bind( s, ... );
connect( s, ... );
send( s, &row, 1 );
send( s, &col, 1 );
send( s, &bAlive, 1 );
recv( s, &byRet, 1 );
closesocket( s );
return byRet;
}
En este estado, la aplicación tiene el peor rendimiento de red posible. Los problemas con esta versión de la aplicación de ejemplo incluyen:
- La aplicación es chatty. Cada transacción es demasiado pequeña: las celdas no necesitan actualizarse una por una.
- Las transacciones se serializan estrictamente, aunque las celdas se puedan actualizar simultáneamente.
- El búfer de envío se establece en cero y la aplicación incurre en un retraso de 200 milisegundos para cada envío, tres veces por celda.
- La aplicación es muy pesada y se conecta una vez para cada celda. Las aplicaciones están limitadas en el número de conexiones por segundo para un destino determinado debido al estado TIME-WAIT, pero no es un problema aquí, ya que cada transacción toma más de 600 milisegundos.
- La aplicación es grasa; muchas transacciones no tienen ningún efecto en el estado del servidor, ya que muchas celdas no cambian de actualización a actualización.
- La aplicación presenta un streaming deficiente; los envíos pequeños consumen mucha CPU y RAM.
- La aplicación asume la representación little-endian de sus envíos. Se trata de una suposición natural para la plataforma Windows actual, pero puede ser peligrosa para el código de larga duración.
Métricas clave de rendimiento
Las siguientes métricas de rendimiento se expresan en Tiempo de ida y vuelta (RTT), Goodput y Sobrecarga del protocolo. Consulte el tema Terminología de red para obtener una explicación de estos términos.
- El tiempo de la celda, el tiempo de red para una única actualización de celda, requiere 4*RTT + 600 milisegundos para las interacciones de Nagle y ACK retrasadas.
- Goodput es inferior a 6 bytes.
- La sobrecarga del protocolo es del 99,6 %.
Temas relacionados