Métricas y kpis de rendimiento de un servidor web

Métricas y kpis de rendimiento de un servidor web.A medida que una aplicación gana más usuarios en un entorno de producción, es cada vez más crítico que comprenda la función del servidor. Para determinar el estado de sus aplicaciones, debe recopilar métricas de rendimiento para los servidores que ejecutan sus aplicaciones web.

Todos los diferentes tipos de servidores web (como Apache, IIS, Azure, AWS y NGINX, por ejemplo) tienen métricas de rendimiento de servidor similares.
Debido a toda esta experiencia que he tenido en los últimos años, he encontrado lo que creo que son ocho de las métricas de rendimiento del servidor más útiles. Estas métricas se pueden dividir en dos categorías: métricas de rendimiento de la aplicación y métricas de experiencia del usuario.

Comencemos mirando las métricas bajo el paraguas del rendimiento de la aplicación .

Tabla de contenidos

Métricas de rendimiento de la aplicación

Las métricas de rendimiento de las aplicaciones son específicas de la velocidad de las aplicaciones web que se ejecutan. Si tiene problemas con el rendimiento lento de una aplicación, estas métricas son un buen lugar para comenzar.

Métrica 1: solicitudes por segundo

Las solicitudes por segundo (también llamado rendimiento) son exactamente como suenan: es la cantidad de solicitudes que recibe su servidor cada segundo. Esta es una métrica fundamental que mide el propósito principal de un servidor web, que es recibir y procesar solicitudes. Las aplicaciones a gran escala pueden alcanzar hasta aproximadamente 2,000 solicitudes por segundo.

Dada suficiente carga, cualquier servidor puede caer. Al considerar el impacto, recuerde que las solicitudes son solo eso: una sola solicitud al servidor. Esta métrica no considera lo que sucede en cada una de estas solicitudes.

Métrica 2: datos de entrada y salida de datos

La siguiente métrica que le sugiero que mire son sus datos de entrada y salida de datos . Los datos en métrica son el tamaño de la carga útil de la solicitud que va al servidor web. Para esta métrica, una tasa más baja es mejor (menor significa que pequeñas cargas útiles se envían al servidor). Unos datos altos en la medición pueden indicar que la aplicación está solicitando más información de la que necesita.

La salida de datos es la carga útil de respuesta que se envía a los clientes. A medida que los sitios web se hacen más grandes con el tiempo , esto causa un problema especialmente para aquellos con conexiones de red más lentas. Las cargas útiles de respuesta hinchada conducen a sitios web lentos, y los sitios web lentos no satisfarán a sus usuarios. Con suficiente lentitud, estos usuarios abandonan el sitio web y continúan. Google sugiere que las páginas que tardan tres o más segundos en cargar los usuarios móviles tienen aproximadamente un 53% de posibilidades de que los usuarios abandonen antes de completar la carga.

Métrica 3: tiempo de respuesta promedio

Definido directamente, el tiempo de respuesta promedio es el tiempo promedio que el servidor tarda en responder a todas las solicitudes que se le hacen. Esta métrica es un fuerte indicador del rendimiento general de la aplicación, dando una impresión de la usabilidad de la aplicación. En general, cuanto menor es este número, mejor. Pero hay estudios que muestran que el límite máximo para un usuario que navega por una aplicación es de alrededor de un segundo.

Al considerar ART, recuerde lo que significa el acrónimo: es solo un promedio. Al igual que todas las métricas determinadas con un promedio, los valores atípicos altos pueden descartar el número por completo y hacer que el sistema parezca más lento de lo que es. El ART es más útil cuando se usa junto con nuestra próxima métrica de la lista.

Métrica 4: Tiempo de respuesta pico

Similar al tiempo de respuesta promedio, el tiempo de respuesta pico (PRT) es la medición de las respuestas más largas para todas las solicitudes que llegan a través del servidor. Este es un buen indicador de los puntos débiles de rendimiento en la aplicación. PRT no solo le dará una idea de qué partes de sus aplicaciones están causando bloqueos; También lo ayudará a encontrar la causa raíz de estos bloqueos. Por ejemplo, si hay una página web lenta o una llamada particularmente lenta, esta métrica puede darle una idea de dónde buscar.

Métrica 5: Utilización de hardware

A continuación, hablemos sobre la utilización general del hardware. Cualquier aplicación o servidor en ejecución está limitado por los recursos que se le asignan. Por lo tanto, realizar un seguimiento de la utilización de los recursos es clave, principalmente para determinar si existe un cuello de botella de recursos. Debe considerar tres aspectos principales de un servidor:

El procesador
La RAM (memoria)
El espacio en disco y el uso

Al considerar estos, está buscando lo que puede convertirse en un cuello de botella para todo el sistema. Como lo mostrará cualquier computadora física (¡o virtual!) Que funcione con estos componentes, el rendimiento es tan fuerte como su eslabón más débil. Esta métrica puede decirle cuál es el cuello de botella y qué componente físico se puede actualizar para mejorar el rendimiento.

Por ejemplo, puede tener problemas al intentar procesar datos desde un disco duro físico. Eso provocará un cuello de botella en las interacciones de E / S entre recopilar archivos y presentarlos al usuario. Mientras el disco duro gira y recopila datos, los otros componentes físicos no hacen nada. Una actualización a una unidad de estado sólido mejoraría el rendimiento de toda la aplicación porque el cuello de botella desaparecerá.

Métrica 6: Conteo de hilos

La siguiente métrica, el recuento de subprocesos de un servidor, le indica cuántas solicitudes concurrentes están ocurriendo en el servidor en un momento determinado. Esta métrica lo ayudará a comprender cómo se ve la carga general de un servidor desde un nivel de solicitud. También le dará una idea de la carga que se coloca en el servidor al ejecutar varios subprocesos.

Un servidor generalmente se puede configurar con un recuento máximo de subprocesos permitido. Al hacer esto, está estableciendo un límite máximo de solicitudes que pueden suceder a la vez. Si el recuento de subprocesos supera este valor máximo, todas las solicitudes restantes se diferirán hasta que haya espacio disponible en la cola para procesarlas. Si estas solicitudes diferidas tardan demasiado, generalmente expiran.

Vale la pena señalar que aumentar el recuento máximo de subprocesos generalmente depende de tener los recursos apropiados disponibles para su uso.

Métricas de experiencia del usuario

Ahora que hemos cubierto las métricas de rendimiento de la aplicación, analicemos algunas centradas en la experiencia del usuario. Estas métricas de rendimiento del servidor pueden medir la satisfacción general de sus usuarios cuando usan sus aplicaciones web.

Métrica 7: Tiempo de actividad

Aunque no está directamente relacionado con su rendimiento, el tiempo de actividad del servidor es una métrica crítica. El tiempo de actividad es el porcentaje que el servidor está disponible para su uso. Idealmente, busca un tiempo de actividad del 100%, y verá muchos casos de tiempo de actividad del 99.9% (o más) cuando busque paquetes de alojamiento web. No es raro que los proyectos de software cumplan con un acuerdo de nivel de servicio que dicta una tasa de tiempo de actividad del servidor en particular. Si la comprobación de métricas de tiempo de actividad no es algo que su servidor puede proporcionarle, hay muchos servicios de terceros, como Updown.io , que pueden hacerlo por usted.

Métrica 8: tasa de error del servidor HTTP

La tasa de error del servidor HTTP es una métrica de rendimiento que no se relaciona directamente con el rendimiento de la aplicación, pero es muy crítica. Devuelve el recuento de errores internos del servidor (o códigos HTTP 5xx) que se devuelven a los clientes. Estos errores se devuelven de mal funcionamiento de las aplicaciones cuando tiene una excepción u otro error que no se maneja correctamente. Una buena práctica es configurar una alerta cada vez que se produce este tipo de errores. Debido a que 500 errores se pueden prevenir casi por completo, puede estar seguro de que tiene una aplicación sólida. Ser notificado de todos los errores del servidor HTTP le permite estar al tanto de cualquier error que ocurra. Esto evita el problema de que se acumulen errores en la aplicación con el tiempo.

Leer también: Kpis esenciales para medir el rendimiento de su sitio web; Tiempo de inactividad del servidor: causas comunes y cómo prevenirlos; ¿Qué es un servidor dedicado?