Necesidades de rendimiento: usuarios y administradores
Los usuarios juzgan el rendimiento de la aplicación por su experiencia:
- ¿La aplicación responde rápidamente?
- ¿Se muestra un icono de reloj de arena mientras se realizan operaciones en segundo plano?
- ¿Se inicia y cierra rápidamente la aplicación?
- ¿Los errores se controlan de una manera comprensible?
En resumen, los usuarios quieren que las aplicaciones sean rápidas y predecibles.
Por el contrario, los administradores suelen juzgar el rendimiento de una aplicación en cuanto a la eficacia que usa los recursos de red. Los administradores pueden preguntar:
- ¿La aplicación tiene una sobrecarga baja y un uso de red eficaz?
- ¿Se usa el número mínimo de conexiones, por lo que mi servidor puede atender tantos usuarios a la vez como sea posible?
- ¿Estoy llamando constantemente al departamento de soporte técnico?
En resumen, los administradores quieren escalar las aplicaciones.
Procedimientos recomendados para las necesidades de rendimiento
Al desarrollar una aplicación de Windows Sockets, estos requisitos de rendimiento se traducen en reglas útiles.
Hacer que las aplicaciones de red se inicialicen rápidamente.
La interfaz de usuario no debe tener que esperar las respuestas de red. Algunas tareas se pueden realizar antes de que la red esté disponible o sin la red. Si la red no responde, es posible que el usuario necesite la interfaz de usuario para operaciones sencillas, como cerrar la aplicación.
No espere a que se cierre la red.
Las aplicaciones cliente-servidor escritas correctamente controlan las desconexiones anulativas correctamente. No inicie una operación potencialmente larga, como sincronizar archivos o carpetas con un servidor, que no se pueden interrumpir al apagarse. Las redes no responden de forma coherente, por lo que incluso las operaciones pequeñas pueden resultar lentas. Proporcione comentarios positivos para los usuarios, incluidas las indicaciones de progreso y los tiempos de finalización estimados.
Asegúrese de una interfaz de usuario con capacidad de respuesta.
La capacidad de respuesta de la aplicación ayuda a eliminar las llamadas innecesarias del departamento de soporte técnico. Una buena guía para la respuesta interactiva es de 500 milisegundos. Los usuarios perciben pausas de más de 500 milisegundos como un retraso en el rendimiento. Las aplicaciones deben tener la capacidad de respuesta suficiente para proporcionar al usuario confianza sobre la aplicación.
Examinar los errores de red.
No todos los errores de red son críticos. Por ejemplo, una aplicación que ha recibido o publicado todos sus datos puede omitir los errores al cerrar la conexión. No suponga que la red o el usuario está disponible; controlar los errores sin intervención del usuario o omitirlos si los errores no son críticos.
Una aplicación debe definir su propio tiempo de espera razonable.
Por ejemplo, una solicitud connect() de Windows Sockets puede bloquearse en algunas condiciones durante un máximo de 21 segundos. Es posible que las aplicaciones necesiten introducir sus propios tiempos de espera según corresponda para sus usuarios.
Minimice la sobrecarga del protocolo.
La conservación del ancho de banda de red consiste en minimizar parcialmente la sobrecarga del protocolo en la que incurre la aplicación. También se trata de eliminar el tráfico de red innecesario. Los protocolos con una sobrecarga de encabezado inferior se pueden usar para transferir datos de la aplicación. Por ejemplo, al enviar cantidades más pequeñas de datos no críticos o repetibles, use UDP en lugar de TCP para reducir la sobrecarga asociada con el establecimiento y el mantenimiento de la conexión. Si se deben enviar los mismos datos a varios destinatarios, considere la posibilidad de multidifusión. Tenga en cuenta que las aplicaciones UDP no están controladas por el flujo; la inserción más allá del ancho de banda disponible puede provocar errores de red catastróficos. La utilidad Netstat se puede usar con sus opciones -e y -s para mostrar las estadísticas de varios protocolos.
Conservar los recursos del sistema.
Los recursos del sistema se pueden consumir rápidamente si no se usa una restricción adecuada. Por ejemplo, los sockets y las conexiones TCP consumen recursos. No use varias conexiones TCP por cliente en las que una sirva para el propósito de la aplicación.
En el caso de las aplicaciones transaccionales, una buena experiencia del usuario y un uso de red bajo no son objetivos conflictivos. La red es un cuello de botella. Las aplicaciones que consumen mucha red pasan más tiempo en espera y las aplicaciones de red bien escritas están diseñadas para minimizar el tiempo de espera innecesario, tanto para la interfaz de usuario como para las transmisiones de red.
Temas relacionados