Comprender al usuario final mediante la supervisión de rendimiento

Siempre estamos supervisando el rendimiento de nuestra CDN desde todos las ubicaciones y proveedores de red posibles en todo el mundo. Esta supervisión del rendimiento es importante tanto para vigilar el estado de la red y los servidores como para comprender y emular la experiencia del usuario final.

Existen varias herramientas para supervisar el rendimiento, pero en este artículo me centraré en Catchpoint. Todos los pasos que veamos también se pueden aplicar a cualquier proveedor de supervisión del rendimiento de terceros que utilices.

¿Por qué debes medir el rendimiento?

El rendimiento es muy importante para cualquier sector que tenga presencia en internet. La conversión y el grado de satisfacción de los usuarios dependen de cómo estos interactúan con tu sitio web o aplicación móvil. Un ejemplo de ello es el caso del experimento de Google de Marissa Mayer. Marissa subió a 30 el número de resultados de búsqueda de Google, lo que provocó que el tráfico y los ingresos disminuyesen un 20 %. Pero ¿a qué se debía esta caída si los usuarios habían pedido más resultados? Mayer investigó el asunto y descubrió que el aumento de los resultados provocó un aumento en el tiempo de carga de las páginas. En concreto, de 0,4 a 0,9 segundos. En definitiva, el tráfico cayó un 20 % por un retraso de medio segundo y el grado de satisfacción de los usuarios empeoró.

La conclusión es que los usuarios tienen en cuenta el rendimiento, de modo que es algo a lo que debes prestar atención.

¿Supervisar la disponibilidad o el rendimiento?

La supervisión de la disponibilidad es clave para garantizar que tu infraestructura esté en perfecto funcionamiento, pero no sirve para conocer la experiencia de tus usuarios finales.

La supervisión de la disponibilidad de la infraestructura te sirve para comprobar que la capacidad de almacenamiento es suficiente, los puertos de red no están al máximo de su capacidad, no hay sobrecargas en el servidor y los componentes de la infraestructura están en buen estado. Por tanto, te centras en las propias métricas de la infraestructura y evalúas los resultados con unidades de medida binarias para saber si el servidor funciona o si necesita más RAM, si tienes que pedir un nuevo puerto de red a tu proveedor de servicios de internet, etc. Todas estas métricas te ofrecen una visión bastante opaca a nivel interno de tu entorno, ya que carece de métricas reales o sintéticas sobre el usuario. Además, suelen utilizarse sobre todo cuando ocurre algo urgente (cuando se produce un fallo, por ejemplo) y no cuentan con información histórica o herramientas de creación de informes.

Sin embargo, la supervisión del rendimiento te permite emular lo que ve el usuario, de modo que puedes entenderlo mucho mejor y ver cómo se comporta la aplicación o el navegador. Si supervisas la disponibilidad, solo puedes tener una visión interna. Pero al supervisar el rendimiento obtienes una visión global y diversa, y sintética o real del usuario y sus navegadores. Así, obtendrás información más completa de lo que ocurre y podrás ir recabando poco a poco datos sobre movimientos, además de evaluar las tendencias históricas. De esta forma, tienes la oportunidad de evolucionar y adaptarte con mayor eficacia.

Cómo mejorar la visibilidad con las herramientas de supervisión de terceros (TPM)

Las TPM te dan una perspectiva del usuario global, además de diversidad de red y distribución geográfica. Aparte, puedes hacer consultas complejas en tus datos, obtener información sobre cada movimiento realizado y emular muchos tipos de puntos de conexión que puedes combinar con tus propios datos.

Con estas herramientas, también obtendrás datos históricos necesarios para correlacionar eventos importantes (como el lanzamiento de una nueva versión de tu software) e información en el nivel de la aplicación sobre qué ocurre en tu stack. También podrás realizar test A/B eficaces y vigilar de cerca a tus proveedores y partners, ya que, por ejemplo, algunos no organizan sus capacidades como debe ser y el rendimiento de tu sitio no se encuentra entre sus prioridades.

De hecho, animamos a todos nuestros clientes a que hagan un seguimiento del rendimiento de Fastly, puesto que es importante conocer a qué nivel rinden todos tus proveedores, sobre todo tu CDN.

Componentes clave para tener en cuenta

A continuación, te explicaré algunos puntos clave sobre la supervisión que deberías tener en cuenta:

• Búsqueda de DNS. El DNS es la base de cualquier movimiento en la red. En el caso de un cliente de Fastly, el proceso consiste en una búsqueda de DNS realizada por el agente de prueba desde su solucionador ascendente. El solucionador respondería con un CNAME o registro A en función de la configuración que el cliente tiene con Fastly. El cliente suele recibir uno o más registros A y lo ideal es que el proveedor de DNS autoritativo (el nuestro es Dyn) reciba estas peticiones en una ubicación geográfica cercana y dé al cliente de la petición la dirección IP del servidor más cercano. Si subcontratas el DNS autoritativo (esperemos que muchos de vosotros uséis NSOne, Dyn o Verisign, por nombrar algunos), este se encargará de realizar las mejoras y solucionar los problemas, así que consúltalo mejor con la empresa correspondiente. Si usas tu propio DNS autoritativo, deberías distribuir estos servidores a nivel global y aprender a usar una red de difusión por proximidad o «anycast» (una tarea nada fácil). Un tema relacionado con esto es que los tiempos de DNS en las herramientas de terceros se «sobrecargan» en comparación con la realidad, pero esto daría para otro artículo.

• Conexión. Básicamente, se trata de establecer una sesión de red de extremo a extremo y una sesión TCP inicial (SYN<>ACK<>SYN/ACK). Si es para capturar el objeto raíz de un sitio web (la URL primaria de www.tusitioweb.com), establecerías una única conexión y ese sería tu tiempo de conexión. Si la prueba la realizas en un sitio web completo, la mayoría de los navegadores tienen seis conexiones simultáneas. Por tanto, asegúrate de entender qué significa la métrica del proveedor de la prueba y a qué se está refiriendo. Esta métrica depende de la latencia del trayecto de ida y vuelta (la entrada predominante) y de cualquier penalización adicional causada por un elemento de hardware sobrecargado. Para mejorar el resultado, puedes aumentar la distribución de la infraestructura tanto a nivel geográfico (por ejemplo, activando nuevas ubicaciones) como a nivel físico (añadiendo más servidores/equilibradores de carga si se encuentran al máximo de su capacidad en las conexiones TCP).

• Protocolo de enlace TLS. Muchos sitios web están adoptando el protocolo TLS en todo el sitio y Google ha empezado a mejorar el posicionamiento de los sitios que utilizan conexiones HTTPS seguras. Ten en cuenta el tiempo que se necesita para establecer el protocolo de enlace TLS, ya que pueden ser necesarios varios trayectos de ida y vuelta que empeoran bastante el tiempo de carga de las páginas. Es por eso que es importante crear las terminaciones de las conexiones TLS lo más cerca posible del usuario (por ejemplo, mediante una CDN). Asegúrate de que tu stack de TLS (o el de tu proveedor) está optimizado. Si usas un proveedor de terceros (CDN o ELB) para crear las terminaciones de las conexiones TLS, no le quites ojo para tener la seguridad de que cuentas con un rendimiento y seguridad buenos.

• WAIT o el primer byte. Cuando la conexión está establecida, WAIT es el tiempo que se tarda en recibir el primer byte de la respuesta para la URL primaria. Para entenderlo mejor, piensa que se trata del tiempo de conexión junto con cualquier penalización adicional del disco por enviar el primer byte de datos de vuelta al cliente. Si el retraso de computación (por ejemplo, el tiempo necesario para capturar una imagen del disco o la RAM) es cero, entonces el WAIT sería igual que el tiempo de conexión. La física establece que el tiempo WAIT nunca puede ser inferior al tiempo de conexión, y una arquitectura con una escalabilidad decente puede tener un delta con una media de dos milisegundos. Si usas una CDN, te lo advierto: en el traspaso de datos (cuando configuras las cachés intermediarias para que no almacenen datos y la CDN tiene que capturar el contenido en origen), el tiempo de WAIT podría diferenciarse bastante del tiempo de conexión.

• Descarga de contenido o LOAD. Es el tiempo entre la carga del primer byte y la carga del último byte para la URL que estés probando. Esto depende de la funcionalidad del ancho de banda, la latencia y el buen funcionamiento de los algoritmos de control del flujo TCP entre el cliente y el servidor. Si haces muchos retoques en el sistema operativo, reducirás el tiempo de LOAD, pero obtendrás mejores resultados al enviar menos datos. Por consiguiente, intenta comprimir todo al máximo. Cualquier navegador moderno será compatible con la compresión gzip, así que puedes configurar esto en tu extremo del servidor web o el equilibrador de carga, o incluso en tu CDN (si utilizas una).

A continuación, tienes un gráfico de rendimiento de Catchpoint (recuerda que la terminología que usamos suele ser propia de Catchpoint, así que puede haber otras maneras de llamar a estos componentes en función de la herramienta) que indica el rendimiento que ha tenido el mismo objeto en una CDN y directamente desde origen. Puedes ver el rendimiento de los cinco componentes que te he explicado y la suma total de todos los componentes individuales, que corresponde al parámetro «respuesta de la página web (ms)».

Siguientes pasos

Es buena idea empezar con una prueba en tu sitio web para ver la puntuación de optimización en Web Page Test. Infórmate con los distintos proveedores de TPM (nosotros preferimos Catchpoint, pero hay otras alternativas), descubre cómo tu proveedor realiza pruebas de rendimiento y no tengas miedo a invertir tiempo y dinero en este proceso. En este caso, no te recomiendo buscar la opción más barata.

Creo que ha quedado bastante claro lo importante que es supervisar el rendimiento para comprender al usuario final. Utiliza los datos que obtengas para centrarte en las métricas principales y mejorar el rendimiento.