Pequeños cambios, grandes ganancias: optimizando escrituras en nuestra DB
En este artículo les voy a contar de una situación que encontramos en el equipo de Performance, en la cual un pequeño cambio en el código generó una gran mejora en los accesos a la Base de datos.
Antes de comenzar, quiero contarles qué es lo que hacemos en el equipo y por qué es tan importante este aprendizaje.
El equipo de Performance se encarga de buscar e implementar mejores soluciones a problemas en el código y la arquitectura de Tiendanube que debido, al gran crecimiento de la base de clientes, podrían quedar más en evidencia al no estar resueltos de la forma más eficiente posible.
Este equipo surgió de manera temporal para la preparación de Hot Sale 2020, pero luego se tomó la decisión de hacerlo permanente.
Una de nuestras principales tablas es donde guardamos los carritos de compra de los usuarios. Como es de esperar esta tabla es una de las que más escrituras tiene. Sin embargo, sospechábamos que varias veces escribíamos en ella más de lo necesario, en base a lo que veíamos en los Performance Insights de la consola de AWS.
Uno de los flujos donde nos enfocamos en particular, era el momento en que se actualizaba un carrito, por ejemplo, al incrementar la cantidad de un producto que ya estaba en él.
Al actualizar el carrito, se restablece cierta información relacionada al envío ya que, al cambiar la composición del mismo, pueden verse modificados todos los precios. Por esta razón, inmediatamente después de esa llamada se realiza una segunda que vuelve a calcular los costos.
Ahora bien, veamos cómo cada una de esas llamadas enviaba la información para guardar cuando el usuario todavía no seleccionó una forma de envío:
Actualización del carrito
{"selected":false,"code":null,"name":null,"price":0,"price_text":0}Actualización de envío
{"selected":false,"code":"","name":"","price":"0","price_text":"0"}Este campo se guarda como un JSON y en el código tenemos una verificación de que el mismo haya cambiado de valor antes de modificarlo.
Sin embargo, podemos ver que el JSON era ligeramente diferente entre las dos llamadas. Esas pequeñas discrepancias eran suficientes para que la actualización se enviara la Base de Datos cada vez. Nuestro pequeño cambio consistió en normalizar la creación de ese JSON para usar los mismos tipos de datos en ambas ocasiones.
Grandes resultados
La siguiente imagen es una muestra de 24 h de las actualizaciones a la tabla de carritos en ambas llamadas, antes de nuestro cambio:
Y este es el escenario con el cambio ya hecho:
Por otro lado, este es el gráfico de Tiempo Promedio para la actualización del carrito, antes y después del cambio:
Y lo mismo para la actualización del envío:
Conclusiones
Como podemos ver en la actualización del carrito, la mejora en el tiempo que pasamos modificando la tabla fue de un 75%. En la actualización del envío, la mejora fue también bastante buena en términos relativos (23%).
Por su parte, en la actualización del carrito podemos notar que, antes del cambio, escribíamos en la Base de Datos por lo menos una vez por ejecución (1,51 veces) y, luego del mismo, pasamos a que esto no siempre suceda (0,364 veces).
Como corolario está el hecho de que a veces no prestamos atención a los valores que, por defecto, usamos o no somos consistentes en su declaración. Si nuestra plataforma va teniendo un incremento progresivo de tráfico, al comienzo tal vez no notemos estas cosas pero, luego de varios años, se van acumulando y puede llegar a impactar negativa y significativamente en la performance.
