A versão de linha de base: um aplicativo de desempenho muito ruim
O exemplo de código inicial de baixo desempenho usado para calcular as atualizações é o seguinte:
Observação
Para simplificar, não há tratamento de erros nos exemplos a seguir. Qualquer aplicativo de produção sempre verifica valores retornados.
Aviso
Os primeiros exemplos do aplicativo fornecem desempenho intencionalmente ruim, a fim de ilustrar melhorias de desempenho possíveis com alterações no código. Não use esses exemplos de código em seu aplicativo; eles são apenas para fins de ilustração.
#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;
}
Nesse estado, o aplicativo tem o pior desempenho de rede possível. Os problemas com esta versão do aplicativo de exemplo incluem:
- O aplicativo é tagarela. Cada transação é muito pequena — as células não precisam ser atualizadas uma a uma.
- As transações são estritamente serializadas, embora as células possam ser atualizadas simultaneamente.
- O buffer de envio é definido como zero e o aplicativo incorre em um atraso de 200 milissegundos para cada envio — três vezes por célula.
- O aplicativo é muito pesado de conexão, conectando-se uma vez para cada célula. Os aplicativos são limitados no número de conexões por segundo para um determinado destino devido ao estado TIME-WAIT, mas isso não é um problema aqui, já que cada transação leva mais de 600 milissegundos.
- O aplicativo é gordo; muitas transações não têm efeito sobre o estado do servidor, porque muitas células não mudam de atualização para atualização.
- O aplicativo exibe streaming insatisfatório; pequenos envios consomem muita CPU e RAM.
- O aplicativo pressupõe uma representação little-endian para seus envios. Essa é uma suposição natural para a plataforma atual do Windows, mas pode ser perigosa para código de longa duração.
Principais métricas de desempenho
As métricas de desempenho a seguir são expressas em RTT (Tempo de Viagem de Ida e Volta), Boa taxa e Sobrecarga de Protocolo. Consulte o tópico Terminologia de Rede para obter uma explicação desses termos.
- Tempo de célula, tempo de rede para uma única atualização de célula, requer 4*RTT + 600 milissegundos para nagle e interações ACK atrasadas.
- A taxa de boas é inferior a 6 bytes.
- A sobrecarga de protocolo é de 99,6%.
Tópicos relacionados