Besoins en performances : utilisateurs et administrateurs
Les utilisateurs jugent les performances de l’application en fonction de leur expérience :
- L’application est-elle rapide à répondre ?
- Une icône de sablier s’affiche-t-elle pendant que des opérations en arrière-plan sont effectuées ?
- L’application se lance-t-elle et se ferme-t-elle rapidement ?
- Les erreurs sont-elles gérées de manière compréhensible ?
Pour résumer, les utilisateurs veulent que les applications soient rapides et prévisibles.
En revanche, les administrateurs jugent souvent les performances d’une application sur l’efficacité de l’utilisation des ressources réseau. Les administrateurs peuvent demander :
- L’application a-t-elle une faible surcharge et une utilisation réseau efficace ?
- Le nombre minimal de connexions est-il utilisé pour que mon serveur puisse traiter autant d’utilisateurs que possible ?
- Est-ce que j’appelle constamment le support technique ?
En bref, les administrateurs veulent que les applications soient mises à l’échelle.
Meilleures pratiques pour les besoins en matière de performances
Lors du développement d’une application Windows Sockets, ces exigences de performances se traduisent par des règles utiles.
Les applications réseau doivent être initialisées rapidement.
L’interface utilisateur ne doit pas avoir à attendre les réponses réseau. Certaines tâches peuvent être effectuées avant que le réseau soit disponible ou sans le réseau. Si le réseau ne répond pas, l’utilisateur peut avoir besoin de l’interface utilisateur pour des opérations simples, telles que la fermeture de l’application.
N’attendez pas l’arrêt du réseau.
Les applications client-serveur correctement écrites gèrent correctement les déconnexions abandonnées. Ne lancez pas une opération potentiellement longue, telle que la synchronisation de fichiers ou de dossiers avec un serveur, qui ne peut pas être interrompue lors de l’arrêt. Les réseaux ne sont pas toujours réactifs, de sorte que même les opérations de petite taille peuvent prendre du temps. Fournir des commentaires positifs aux utilisateurs, y compris des indications de progression et des délais d’achèvement estimés.
Assurez-vous d’une interface utilisateur réactive.
La réactivité des applications permet d’éliminer les appels inutiles au support technique. Une bonne ligne directrice pour la réponse interactive est de 500 millisecondes. Les utilisateurs perçoivent les pauses de plus de 500 millisecondes comme un décalage dans les performances. Les applications doivent être suffisamment réactives pour fournir à l’utilisateur la confiance de l’application.
Examinez les erreurs réseau.
Toutes les erreurs réseau ne sont pas critiques. Par exemple, une application qui a reçu ou publié toutes ses données peut probablement ignorer les erreurs lors de la fermeture de la connexion. Ne supposez pas que le réseau ou l’utilisateur est disponible ; gérez les erreurs sans intervention de l’utilisateur ou ignorez-les si les erreurs ne sont pas critiques.
Une application doit définir ses propres délais d’expiration raisonnables.
Par exemple, une demande windows Sockets connect() peut bloquer dans certaines conditions pendant 21 secondes. Les applications peuvent avoir besoin d’introduire leurs propres délais d’expiration en fonction des besoins de leurs utilisateurs.
Réduisez la surcharge de protocole.
La conservation de la bande passante réseau consiste en partie à réduire la surcharge de protocole encourue par votre application. Il s’agit également d’éliminer le trafic réseau inutile. Les protocoles avec une surcharge d’en-tête inférieure peuvent être utilisés pour transférer des données d’application. Par exemple, lorsque vous envoyez de plus petites quantités de données non critiques ou reproductibles, utilisez UDP par opposition à TCP pour réduire la surcharge associée à l’établissement et à la maintenance de la connexion. Si les mêmes données doivent être envoyées à plusieurs destinataires, envisagez la multidiffusion. N’oubliez pas que les applications UDP ne sont pas contrôlées par le flux. Le fait de pousser au-delà de la bande passante disponible peut entraîner une défaillance réseau catastrophique. L’utilitaire Netstat peut être utilisé avec ses options -e et -s pour afficher des statistiques pour différents protocoles.
Conservez les ressources système.
Les ressources système peuvent être consommées rapidement si une contrainte appropriée n’est pas utilisée. Par exemple, les sockets et les connexions TCP consomment des ressources. N’utilisez pas plusieurs connexions TCP par client où l’une d’elles servira l’objectif de l’application.
Pour les applications transactionnelles, une bonne expérience utilisateur et une faible utilisation du réseau ne sont pas des objectifs contradictoires. Le réseau est un goulot d’étranglement. Les applications gourmandes en réseau passent plus de temps à attendre, et les applications réseau bien écrites sont conçues pour réduire les temps d’attente inutiles, à la fois pour l’interface utilisateur et pour les transmissions réseau.
Rubriques connexes