Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los usuarios juzgarán 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?
- ¿La aplicación se inicia y cierra rápidamente?
- ¿Los errores se controlan de forma 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 eficaz de la red?
- ¿Se usa el número mínimo de conexiones, por lo que mi servidor puede atender tantos usuarios como sea posible?
- ¿Estoy llamando constantemente al departamento de soporte técnico?
En resumen, los administradores quieren que las aplicaciones se escalen.
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 de servidor cliente escritas correctamente controlan las desconexiones anulativas correctamente. No inicie una operación potencialmente larga, como la sincronización de 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 podrían 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 al 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 retraso en el rendimiento. Las aplicaciones deben responder lo suficiente para proporcionar al usuario confianza sobre la aplicación.
Examine 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 errores al cerrar la conexión. No asuma que la red o el usuario están disponibles; controla los errores sin intervención del usuario o los omite 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 hasta 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 parcialmente en minimizar la sobrecarga del protocolo 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 un error de red grave. La utilidad Netstat se puede usar con sus opciones de -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 la restricción adecuada. Por ejemplo, los sockets y las conexiones TCP consumen recursos. No use varias conexiones TCP por cliente, donde una servirá para el propósito de la aplicación.
En el caso de las aplicaciones transaccionales, la buena experiencia del usuario y el uso bajo de la red no son objetivos conflictivos. La red es un cuello de botella. Las aplicaciones que consumen mucho 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