Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Os usuários avaliam o desempenho do aplicativo por sua experiência:
- A aplicação é rápida a 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 forma 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 com base na eficiência com que ele usa os recursos da rede. Os administradores podem perguntar:
- O aplicativo tem baixa sobrecarga e uso eficiente da rede?
- O número mínimo de conexões é usado, para que meu servidor possa atender o maior número possível de usuários ao mesmo tempo?
- Estou constantemente ligando para o helpdesk?
Em resumo, 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 ter que esperar por respostas de rede. Algumas tarefas podem ser executadas antes de a rede estar disponível ou sem a rede. Se a rede não estiver respondendo, o usuário pode precisar da interface do usuário para operações simples, como fechar o aplicativo.
Não aguarde o desligamento da rede.
Aplicativos cliente-servidor escritos corretamente lidam com desconexões abortivas normalmente. Não inicie uma operação potencialmente longa, como sincronizar arquivos ou pastas com um servidor, que não possa ser interrompida no desligamento. As redes não respondem de forma consistente, pelo que mesmo pequenas operações podem ser morosas. Fornecer feedback positivo aos utilizadores, incluindo indicações de progresso e tempos de conclusão estimados.
Garanta uma interface de usuário responsiva.
A capacidade de resposta do aplicativo ajuda a eliminar chamadas desnecessárias de helpdesk. 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 ao usuário confiança sobre o aplicativo.
Analise os 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 assuma que a rede ou o utilizador estão disponíveis; Manipule erros sem intervenção do usuário ou ignore-os se os erros não forem críticos.
Um pedido deve definir os seus próprios prazos 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 limites, conforme apropriado para seus usuários.
Minimize a sobrecarga de protocolo.
Conservar a largura de banda da rede é, em parte, 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 tiverem de ser enviados para vários destinatários, considere o multicast. Lembre-se de que os aplicativos UDP não são controlados por fluxo — ir além da largura de banda disponível pode causar falhas catastróficas na rede. O utilitário Netstat pode ser usado com suas opções -e e -s para exibir estatísticas para vários protocolos.
Conserve os recursos do sistema.
Os recursos do sistema podem 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 onde uma servirá o propósito do aplicativo.
Para aplicativos transacionais, a boa experiência do usuário e a baixa utilização da rede não são objetivos conflitantes. A rede é um gargalo. Aplicativos com uso intensivo de rede passam mais tempo esperando, 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