Necessidades de desempenho: usuários e administradores
Os usuários avaliam o desempenho do aplicativo por sua experiência:
- O aplicativo é rápido em responder?
- Um ícone de ampulheta é exibido enquanto as operações em segundo plano são realizadas?
- O aplicativo é iniciado e fechado rapidamente?
- Os erros são tratados de maneira compreensível?
Para resumir, os usuários querem que os aplicativos sejam rápidos e previsíveis.
Por outro lado, os administradores geralmente julgam o desempenho de um aplicativo sobre a eficiência com que ele usa recursos de rede. Os administradores podem perguntar:
- O aplicativo tem baixa sobrecarga e uso eficiente de rede?
- O número mínimo de conexões é usado, para que meu servidor possa atender ao máximo de usuários ao mesmo tempo possível?
- Estou constantemente chamando assistência técnica?
Em suma, os administradores querem que os aplicativos sejam dimensionados.
Práticas recomendadas para necessidades de desempenho
Ao desenvolver um aplicativo windows sockets, esses requisitos de desempenho se traduzem em regras úteis.
Faça com que os aplicativos de rede sejam inicializados rapidamente.
A interface do usuário não deve precisar aguardar respostas de rede. Algumas tarefas podem ser executadas antes que a rede esteja disponível ou sem a rede. Se a rede não estiver respondendo, o usuário poderá precisar da interface do usuário para operações simples, como fechar o aplicativo.
Não aguarde o desligamento da rede.
Os aplicativos cliente-servidor gravados corretamente lidam com desconexões abortivas normalmente. Não inicie uma operação potencialmente demorada, como sincronizar arquivos ou pastas com um servidor, que não pode ser interrompida no desligamento. As redes não são consistentemente responsivas, portanto, mesmo pequenas operações podem ser demoradas. Forneça comentários positivos para os usuários, incluindo indicações de progresso e tempos estimados de conclusão.
Garanta uma interface do usuário responsiva.
A capacidade de resposta do aplicativo ajuda a eliminar chamadas de assistência técnica desnecessárias. Uma boa diretriz para resposta interativa é 500 milissegundos. Os usuários percebem pausas superiores a 500 milissegundos como um atraso no desempenho. Os aplicativos devem ser responsivos o suficiente para fornecer confiança ao usuário sobre o aplicativo.
Examinar erros de rede.
Nem todos os erros de rede são críticos. Por exemplo, um aplicativo que recebeu ou postou todos os seus dados provavelmente pode ignorar erros ao fechar a conexão. Não suponha que a rede ou o usuário esteja disponível; manipular erros sem intervenção do usuário ou ignorá-los se os erros não forem críticos.
Um aplicativo deve definir seus próprios tempos limite razoáveis.
Por exemplo, uma solicitação connect() do Windows Sockets pode ser bloqueada em algumas condições por até 21 segundos. Os aplicativos podem precisar introduzir seus próprios tempos limite conforme apropriado para seus usuários.
Minimizar a sobrecarga do protocolo.
Conservar a largura de banda de rede é parcialmente sobre minimizar a sobrecarga de protocolo incorrida pelo seu aplicativo. Trata-se também de eliminar o tráfego de rede desnecessário. Protocolos com uma sobrecarga de cabeçalho inferior podem ser usados para transferir dados do aplicativo. Por exemplo, ao enviar quantidades menores de dados não críticos ou repetíveis, use UDP em vez de TCP para reduzir a sobrecarga associada ao estabelecimento e à manutenção da conexão. Se os mesmos dados precisarem ser enviados para vários destinatários, considere multicast. Lembre-se de que os aplicativos UDP não são controlados por fluxo— efetuar push além da largura de banda disponível pode causar uma falha catastrófica na rede. O utilitário Netstat pode ser usado com suas opções -ee-s para exibir estatísticas para vários protocolos.
Conservar recursos do sistema.
Os recursos do sistema poderão ser consumidos rapidamente se a contenção adequada não for usada. Por exemplo, soquetes e conexões TCP consomem recursos. Não use várias conexões TCP por cliente em que uma delas atenda à finalidade do aplicativo.
Para aplicativos transacionais, boa experiência do usuário e baixa utilização de rede não são metas conflitantes. A rede é um gargalo. Aplicativos com uso intensivo de rede gastam mais tempo aguardando e aplicativos de rede bem escritos são projetados para minimizar o tempo de espera desnecessário, tanto para a interface do usuário quanto para transmissões de rede.
Tópicos relacionados