¡Hola comunidad! A continuación podrán disfrutar de la última actualización de desarrollo anunciada por el equipo de BlockTrades. Esta es una traducción del post original
En este anuncio nos hablan de las mejoras al host de imágenes de Hive (Hive imagehoster), la mejoras del tiempo de respuestas y nos comentan sobre como fue el proceso de encontrar los errores e ir mejorando, un punto importante son los avatares de los perfiles de los usuarios y como se ha mejorado el tiempo de respuesta.
Se solucionaron un conjunto de problemas de caché y otros para tener la mejora que experimentamos hoy día, ten en cuenta que puedes encontrar terminología técnica en este post.
Informaré sobre nuestro trabajo de desarrollo general más adelante (probablemente la semana que viene), pero en los últimos días hemos realizado algunas mejoras en la infraestructura de imagehoster que creo que merece la pena compartir ahora.
Hive imagehoster
Como muchos de ustedes saben, BlockTrades opera el sistema imagehoster que sirve imágenes para los posts de Hive renderizados por los distintos frontends de Hive (hive.blog, ecency, peakd, etc). Por ejemplo, la imagen que encabeza este post se almacena en ese sistema.
Dado que muchos de los servicios de redes sociales de Hive dependen del imagehoster para proporcionar imágenes, el tiempo total de renderización de las páginas en estos sitios se ve afectado por la velocidad a la que el imagehoster suministra imágenes a los navegadores web de los usuarios, lo que a la larga afecta tanto a la experiencia del usuario como incluso a algunas formas de clasificación web de los sitios, por lo que queremos que el servidor sea lo más rápido posible.
Además, de vez en cuando, el imagehoster tendrá problemas de un tipo u otro que pueden provocar que las imágenes no se muestren en los sitios web de Hive.
Pero estos problemas suelen solucionarse simplemente reiniciando el proceso de imagehoster de vez en cuando. Así que no hemos centrado muchos de nuestros esfuerzos de desarrollo en el imagehoster, ya que en su mayoría hace lo que se supone que debe hacer razonablemente bien, y no éramos conscientes de ninguna mejora fácil de hacer que no hubiéramos hecho ya.
Sin embargo, la semana pasada vimos un caso en el que el imagehoster se cargaba mucho, lo que provocaba que algunas imágenes no aparecieran en los sitios Hive, pero un simple reinicio no solucionaba el problema, así que empezamos a investigarlo más a fondo.
Peticiones de Imagehoster
Para ver cómo analizamos el problema, primero tenemos que refrescar qué tipos de peticiones procesa el imagehoster y cómo está configurado el sistema imagehoster.
La petición imagehoster más simple de entender es una petición directa de una imagen en particular (la llamaremos petición de imagen). Una petición de imagen siempre devuelve los mismos datos de imagen, como probablemente esperarías.
Pero el imagehoster también procesa peticiones de "avatar". Un avatar es la imagen que un usuario asocia a su cuenta de Hive, y el usuario puede cambiar esta imagen generando una transacción Hive apropiada y publicándola en la cadena de bloques de Hive.
Por tanto, para procesar una solicitud de avatar, el imagehoster debe realizar otra solicitud interna para averiguar qué imagen ha asociado el usuario por última vez a su cuenta (para los chicos de la web, añadiré que esto se hace mediante una redirección 302).
Este mapeo de redirección entre una cuenta Hive y el nombre de la imagen avatar se almacena dentro de hived. Así que cada vez que se hace una solicitud de avatar al imagehoster, el imagehoster entonces hace una llamada get_accounts a un nodo hived para averiguar qué imagen necesita buscar, y sólo entonces podemos buscar y devolver la imagen apropiada.
Cuando empezamos a estudiar este problema, suponíamos que las solicitudes de avatares serían las más rápidas, a pesar de requerir un paso de búsqueda adicional, porque se suponía que el paso de búsqueda era rápido y las imágenes de avatares son mucho más pequeñas que la mayoría de las demás imágenes. Pero resulta que ese tiempo extra de búsqueda jugaba un papel clave en el problema que teníamos...
Configuración del sistema Imagehoster
Así es como una solicitud de imagen es procesada por el sistema imagehoster: 1) el navegador de un usuario hace una solicitud de imagen o una solicitud de avatar al ordenador imagehoster, 2) la solicitud a nuestro ordenador es interceptada primero por cloudflare (configuramos cloudflare de esta manera para ayudarnos a almacenar en caché los datos de la imagen y reducir la carga en el ordenador imagehoster), 3) cloudflare responderá por nuestro ordenador si los datos solicitados ya están en su caché, o si no, pasará la solicitud al servidor web nginx que se ejecuta en nuestro ordenador, 4) nuestro servidor nginx entonces enruta esta solicitud a nuestra caché local varnish, 5) Si la imagen no está en la caché de varnish, la solicitud se pasa a nuestro servidor haproxy, que a su vez pasa la solicitud al propio imagehoster, 6) Si se trata de una imagen, el imagehoster responde con la imagen, o si se trata de una solicitud de avatar hace una llamada get_accounts a nuestro nodo hived para encontrar la imagen asociada, entonces ese nombre de archivo de imagen se devuelve al navegador del usuario y su navegador hará una solicitud de seguimiento al imagehoster para esa imagen.
Analizar el problema: buscar indicios de por qué fallan las solicitudes.
Inicialmente, la única forma en que podíamos ver un problema con el imagehoster era navegando por las páginas web en los diversos sitios web de los post de Hive y ver las imágenes que faltaban, así que empezamos por cavar a través de diversos informes de software de monitoreo y registros del servidor para buscar posibles problemas con los recursos informáticos disponibles (CPU, memoria, espacio en disco, las limitaciones de software, etc). Al principio fue un poco frustrante, porque no veíamos ninguno de los problemas obvios de carga de los tipos que suelen asociarse a un servidor sobrecargado.
No hay suficientes conexiones tipo worker
Una cosa que encontramos al principio durante esta búsqueda de pistas fue que durante el tiempo en que el imagehoster estaba teniendo problemas, había un montón de estos mensajes en los registros de error del servidor nginx:
"worker_connections are not enough".
Un servidor nginx sólo permite un número determinado de conexiones tipo worker (que influye en el número de solicitudes de imágenes activas que el servidor puede manejar en un momento dado). Si el sistema imagehoster empieza a tardar más en procesar las solicitudes, el imagehoster puede quedarse sin conexiones worker disponibles porque todas están ocupadas con solicitudes más antiguas.
Es posible aumentar el número de conexiones worker nginx, pero en poco tiempo empezarás a encontrarte con límites relacionados con el número abierto de gestores de archivos del sistema. También es posible aumentar el número de gestores de archivos del sistema, pero realmente no quieres hacer este tipo de ajustes a tu sistema: la mejor solución es tratar de reducir el tiempo que tu servidor tarda en responder a las peticiones, lo que te permite procesar más peticiones con el mismo número de conexiones tipo worker (trabajar más inteligentemente, no más duro).
Identificación de las peticiones problemáticas
Ahora que teníamos una buena pista de que las conexiones worker eran el cuello de botella, nuestra siguiente tarea era averiguar qué peticiones estaban causando el problema. Esto no es tan fácil como podría parecer, porque aunque podíamos ver qué peticiones individuales estaban fallando, no eran necesariamente las peticiones problemáticas, podrían ser simplemente la petición desafortunada que llegó durante un tiempo en el que un trabajador no estaba disponible lo suficientemente rápido. Así que lo que realmente necesitábamos hacer era averiguar qué peticiones estaban tardando mucho tiempo, no cuáles estaban fallando.
Como sabíamos que teníamos dos tipos diferentes de peticiones (imagen frente a avatar), pensamos que era posible que uno u otro tipo fuera el principal culpable. Así que dividimos estos dos tipos de tráfico en dos puertos diferentes en haproxy, lo que nos permitió obtener estadísticas separadas de haproxy sobre los dos tipos de peticiones diferentes (también tuvimos que habilitar la página de estadísticas de haproxy para recopilar estos datos, lo que nunca nos habíamos molestado en hacer para el imagehoster antes).
Las solicitudes de avatares son más lentas de lo esperado
Y aquí llegó nuestra primera sorpresa: descubrimos que, en realidad, las solicitudes de avatares tardaban más que las de imágenes, cuando suponíamos lo contrario. Aún más sorprendente, no era sólo el "tiempo total" para obtener la redirección de la imagen + la posterior obtención de la imagen para el avatar lo que estaba llevando más tiempo, era sólo el tiempo de redirección el que dominaba.
En este punto, se hizo evidente un problema inmediato: la petición de redirección se estaba realizando a un nodo colgado situado en un ordenador diferente. Así que mientras nos habíamos centrado en el tamaño de los datos de la imagen y el tiempo para leer los datos de los discos duros locales como el problema probable, el verdadero problema era la latencia de ~ 300ms asociada con la obtención de los datos de redirección relativamente pequeños de otro equipo ubicado en un continente diferente.
Usando un hived local para reducir la latencia
Afortunadamente, teníamos una solución sencilla para este problema: configuramos un nodo hived local en el ordenador imagehoster, y ahora las subpeticiones de redirección medidas desde haproxy bajaron de 300+ ms a 6ms.
Este cambio mejoró drásticamente los tiempos de renderizado de las páginas en hive.blog y mejoró la experiencia de navegación del usuario. Por lo que podemos decir hasta ahora, esto también parece haber resuelto el problema "worker_connections are not enough" que provocaba la pérdida de imágenes. Llevamos más de 24 horas sin ver esos mensajes en los registros, pero necesitaremos un par de días más de monitorización para estar completamente seguros.
Así que en este momento, el cuello de botella para el procesamiento de las solicitudes de avatares no almacenados en caché es ahora sólo el tiempo de latencia desde el navegador del usuario hasta el servidor de imágenes. Todavía es posible obtener mejores tiempos de respuesta en el caso de que la respuesta a la solicitud de avatar sea almacenada en caché por cloudflare, ya que los servidores de caché de cloudflare tienden a tener tiempos de latencia más bajos hasta el ordenador del usuario, y hablaré de cómo hemos atacado el problema del almacenamiento en caché en la siguiente sección.
Problemas de caché
Otro problema que observamos mientras buscábamos formas de mejorar el rendimiento del servidor fue que las peticiones al imagehoster no se almacenaban en caché tan bien como habríamos previsto.
Peor aún, descubrimos que las peticiones de "redirección" de avatares superpequeñas se almacenaban en caché peor que las peticiones de imágenes (esto nos llevó un poco de experimentación para determinarlo, ya que casi no tenemos acceso a la caché de cloudflare y sólo podemos observar los resultados en la ventana de depuración de un navegador web para ver los fallos de caché, pero al final nos convencimos de que este era el caso).
Los redireccionamientos de avatares son realmente pequeños, por lo que una caché debería ser capaz de almacenarlos casi todos, y las mismas búsquedas de avatares deberían ser frecuentes, asegurando así que un algoritmo de caché basado en LRU tendería a favorecer el almacenamiento en caché de los redireccionamientos de avatares en lugar de imágenes obtenidas más ocasionalmente en entradas individuales. Esta es otra razón por la que nos sorprendió que las solicitudes de avatares estuvieran causando la carga problemática en nuestro sistema: originalmente esperábamos que cloudflare almacenara en caché la mayoría de estas solicitudes para que nuestro servidor rara vez tuviera que gestionarlas.
¿Caducidad de la caché en 6 horas frente a 10 minutos?
Resulta que el tiempo de caducidad de 6 horas que estábamos viendo en la respuesta de la solicitud no estaba siendo establecido por el imagehoster. El código imagehoster establece el encabezado de caducidad a 10 minutos (que es el tiempo que realmente estábamos viendo expiraciones ocurrir en cloudflare y en varnish). Así que hemos llegado a la conclusión de que es probablemente cloudflare que por alguna razón desconocida para nosotros está reescribiendo el tiempo de caducidad del encabezado a 6 horas. Presumiblemente, esto tendrá un impacto en el tiempo de almacenamiento en caché en los navegadores locales que tienen habilitado el almacenamiento en caché.
Así que, a continuación, cambiamos el código de imagehoster para aumentar el tiempo de caducidad de las solicitudes de avatar de 10 minutos a un día. Con este ajuste, el tiempo de expiración ya no se reescribe, y aparece con el tiempo de expiración especificado en las cabeceras de respuesta vistas en un navegador. Hemos cambiado el tiempo de caducidad de "para siempre" a un día para restablecer la situación deseada en caso de que el servicio que caduca los avatares modificados falle por algún motivo.
Y esto, por supuesto, también "fijo" cloudflare almacenamiento en caché para almacenar las imágenes durante más de 10 minutos. Así que cuando inspeccionamos las cabeceras de respuesta de avatar en un navegador, generalmente vemos que casi todas las solicitudes de avatar están siendo almacenadas en caché por cloudflare ahora.
Caché de Varnish generalmente ineficaz en este momento
Dado que estamos utilizando cloudflare para el almacenamiento en caché, en este momento el segundo nivel de caché de varnish no está ayudando mucho, ya que parece que la caché de varnish no es mayor que la caché de cloudflare (sólo hemos dado 8 GB a la caché de Varnish y no sabemos lo grande que es la caché de cloudflare). Pero la caché de cloudflare está haciendo el trabajo lo suficientemente bien, por lo que no parece haber ninguna necesidad inmediata de experimentar con el aumento del tamaño de la caché de varnish.
Varnish Cache es un acelerador de aplicaciones web, también conocido como caché de proxy HTTP inversa.
¿Qué tipo de mejora hemos obtenido tras los cambios?
Antes de los cambios, los tiempos de respuesta para una solicitud de avatar que no llegaba a la caché eran de más de 700 ms y se producían muchos errores de caché. Ahora rara vez se produce una pérdida de caché y los tiempos de respuesta oscilan entre 25 y 140 ms (la primera vez que solicitamos un nuevo avatar en nuestro navegador tarda unos 140 ms, la segunda vez unos 25 ms, lo que especulamos que se debe a que un servidor de borde comienza a almacenarlo en caché más cerca de nuestro navegador después de la primera búsqueda).
Rara vez vemos un fallo de caché, pero podemos suponer que estos fallos de caché tardarán alrededor de 100 ms adicionales para nosotros, ya que estamos en un continente diferente del imagehoster (por lo que probablemente entre 140-400 ms basado en nuestras solicitudes de prueba para los avatares no existentes).
Muchas gracias al team BlockTrades por todo el trabajo que realizan para Hive.
✔️¡Mantente al día con la comunidad de Hive Español!
🚀Ingresa a Hive: hive.io
🔗X: hiveblocks_es
🤳Instagram: hiveblocks_es
➡️Telegram: t.me/hiveblockes
👉YouTube: hiveblocks_es/videos
Congratulations @hiveblocks-es! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)
Your next target is to reach 70 posts.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOP