En Memoria de las Dificultades

Hola, mi nombre es Gabriel. Trabajo en auction.com y voy a hablar sobre cómo mejoramos el rendimiento de los resolvers de GraphQL para nuestro servicio de GraphQL. Tuvimos un problema con nuestra implementación de suscripción, donde experimentábamos un alto número de reinicios debido a fallos en la asignación de memoria. Esto nos llevó a investigar y optimizar el consumo de memoria de nuestros resolvers. Para evaluar el rendimiento, configuramos un entorno local con Kafka, Graph y un cliente que conectó 4000 WebSockets a Graph. Después de realizar la prueba, descubrimos que solo podíamos procesar y distribuir 16 mensajes a nuestros clientes. Yay. El gráfico de consumo de memoria mostró picos y valles a medida que se entregaban los mensajes. Se observaron tres fases distintas: inactivo, Sockets conectados sin mensajes y mensajes siendo procesados. Decidimos optimizar el contexto, que contiene información específica de la solicitud y detalles del backend. Dado que las suscripciones implican principalmente el envío de mensajes Kafka, nos dimos cuenta de que el mensaje en sí a menudo tiene toda la información necesaria. Por lo tanto, solo creamos backends cuando se realiza una llamada a ellos. Optimizamos nuestro proceso de creación de backends utilizando el objeto proxy, lo que nos permite crear backends de manera perezosa solo cuando se acceden. Esto resultó en un menor consumo de memoria sin cambiar el código o el esquema. El menor consumo de memoria es evidente en la segunda fase de la grabación, donde el plateau formado por tener múltiples contextos es significativamente más bajo. La mayoría de los ahorros se lograron reduciendo objetos temporales y utilizando iteradores nativos en lugar de llamadas Lodash para convertir nombres de claves a Snakecase. De repente, el rendimiento aumentó en un 18%, lo que resultó en un mayor consumo de memoria. Actualizar a versiones más nuevas de GraphQL Redis subscriptions no tuvo un impacto significativo en el uso de memoria. Sin embargo, optimizar la conversión de nombres de claves a snake case mediante el uso de memoización mejoró la eficiencia computacional. Nuestro rendimiento mejoró significativamente después de implementar snake case. Sin embargo, el consumo de memoria seguía siendo alto. Para abordar la fuga de memoria, introdujimos autoescalado y reiniciamos el servicio cada noche. Además, optimizamos el proceso de generación de código para mejorar el consumo de memoria. Exploramos el uso de instantáneas de heap en Google Dev tools para analizar y reducir el consumo de memoria. Al identificar objetos innecesarios y eliminarlos, pudimos liberar memoria y mejorar el rendimiento. Corregimos el objeto de ubicación para mejorar el rendimiento y reducir el consumo de memoria. También optimizamos los cargadores de datos para evitar consultas N+1 y mejorar la eficiencia.